Re: [Qemu-devel] [PULL] slirp: Fix issues with -mms-bitfields

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 4168 bytes --]

On 2011-08-25 14:02, TeLeMan wrote:
> On Thu, Aug 25, 2011 at 19:04, Jan Kiszka <jan.kiszka@web.de> wrote:
>> On 2011-08-25 03:14, TeLeMan wrote:
>>> On Wed, Aug 24, 2011 at 17:11, Jan Kiszka <jan.kiszka@web.de> wrote:
>>>> On 2011-08-23 12:49, TeLeMan wrote:
>>>>> On Sun, Aug 21, 2011 at 04:00, Stefan Weil <weil@mail.berlios.de> wrote:
>>>>>> Am 15.08.2011 08:39, schrieb Jan Kiszka:
>>>>>>>
>>>>>>> The following changes since commit
>>>>>>> 3b6ffe50300f13240e1b46420ad05da1116df410:
>>>>>>>
>>>>>>> hw/scsi-bus.c: Fix use of uninitialised variable (2011-08-14 19:34:25
>>>>>>> +0000)
>>>>>>>
>>>>>>> are available in the git repository at:
>>>>>>> git://git.kiszka.org/qemu.git queues/slirp
>>>>>>>
>>>>>>> Jan Kiszka (1):
>>>>>>> slirp: Fix bit field types in IP header structs
>>>>>>>
>>>>>>> slirp/ip.h | 8 ++++----
>>>>>>> slirp/tcp.h | 4 ++--
>>>>>>> 2 files changed, 6 insertions(+), 6 deletions(-)
>>>>>>>
>>>>>>> ---
>>>>>>>
>>>>>>> slirp: Fix bit field types in IP header structs
>>>>>>>
>>>>>>> -mms-bitfields prevents that the bitfields in current IP header structs
>>>>>>> are packed into a single byte as it is required. Fix this by using
>>>>>>> uint8_t as backing type.
>>>>>>>
>>>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>>> ---
>>>>>>> slirp/ip.h | 8 ++++----
>>>>>>> slirp/tcp.h | 4 ++--
>>>>>>> 2 files changed, 6 insertions(+), 6 deletions(-)
>>>>>>>
>>>>>>> diff --git a/slirp/ip.h b/slirp/ip.h
>>>>>>> index 48ea38e..72dbe9a 100644
>>>>>>> --- a/slirp/ip.h
>>>>>>> +++ b/slirp/ip.h
>>>>>>> @@ -74,10 +74,10 @@ typedef uint32_t n_long; /* long as received from the
>>>>>>> net */
>>>>>>> */
>>>>>>> struct ip {
>>>>>>> #ifdef HOST_WORDS_BIGENDIAN
>>>>>>> - u_int ip_v:4, /* version */
>>>>>>> + uint8_t ip_v:4, /* version */
>>>>>>> ip_hl:4; /* header length */
>>>>>>> #else
>>>>>>> - u_int ip_hl:4, /* header length */
>>>>>>> + uint8_t ip_hl:4, /* header length */
>>>>>>> ip_v:4; /* version */
>>>>>>> #endif
>>>>>>> uint8_t ip_tos; /* type of service */
>>>>>>> @@ -140,10 +140,10 @@ struct ip_timestamp {
>>>>>>> uint8_t ipt_len; /* size of structure (variable) */
>>>>>>> uint8_t ipt_ptr; /* index of current entry */
>>>>>>> #ifdef HOST_WORDS_BIGENDIAN
>>>>>>> - u_int ipt_oflw:4, /* overflow counter */
>>>>>>> + uint8_t ipt_oflw:4, /* overflow counter */
>>>>>>> ipt_flg:4; /* flags, see below */
>>>>>>> #else
>>>>>>> - u_int ipt_flg:4, /* flags, see below */
>>>>>>> + uint8_t ipt_flg:4, /* flags, see below */
>>>>>>> ipt_oflw:4; /* overflow counter */
>>>>>>> #endif
>>>>>>> union ipt_timestamp {
>>>>>>> diff --git a/slirp/tcp.h b/slirp/tcp.h
>>>>>>> index 9d06836..b3817cb 100644
>>>>>>> --- a/slirp/tcp.h
>>>>>>> +++ b/slirp/tcp.h
>>>>>>> @@ -51,10 +51,10 @@ struct tcphdr {
>>>>>>> tcp_seq th_seq; /* sequence number */
>>>>>>> tcp_seq th_ack; /* acknowledgement number */
>>>>>>> #ifdef HOST_WORDS_BIGENDIAN
>>>>>>> - u_int th_off:4, /* data offset */
>>>>>>> + uint8_t th_off:4, /* data offset */
>>>>>>> th_x2:4; /* (unused) */
>>>>>>> #else
>>>>>>> - u_int th_x2:4, /* (unused) */
>>>>>>> + uint8_t th_x2:4, /* (unused) */
>>>>>>> th_off:4; /* data offset */
>>>>>>> #endif
>>>>>>> uint8_t th_flags;
>>>>>>
>>>>>> Tested-by: Stefan Weil <weil@mail.berlios.de>
>>>>>>
>>>>> slirp is still broken on my mingw32. I used "#progma
>>>>> pack(push,1)/#progma pack(pop)" to resolve this issue.
>>>>
>>>> Can you drill down to the bottom of this problem? What fields in what
>>>> struct are not properly packed? Maybe this is now a compiler bug, so
>>>> comparing versions may make sense as well.
>>> arphdr.ar_sip is not aligned on  a 4-byte boundary. See my previous post:
>>> http://lists.gnu.org/archive/html/qemu-devel/2011-08/msg00964.html
>>
>> What a mess. Do we really have to go through all 257 packed data structs
>> in QEMU and add these MS compat bits to all potentially affected ones?
> I prefer to detect -mms-bitfields and remove it in configure.

/me too - if that is possible, ie. if the glib bits we are using doesn't
require us to apply that mode. Can anyone comment on this?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]