Re: [Xen-devel] [PATCH 2/5] xen/common: Cleanup use of __attribute__((packed))

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.03.14 at 11:22, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> On 13/03/14 08:15, Jan Beulich wrote:
>>>>> On 12.03.14 at 20:08, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
>>> --- a/xen/common/trace.c
>>> +++ b/xen/common/trace.c
>>> @@ -641,11 +641,11 @@ static inline void insert_wrap_record(struct t_buf 
>>> *buf,
>>>  
>>>  static inline void insert_lost_records(struct t_buf *buf)
>>>  {
>>> -    struct {
>>> +    struct __packed {
>>>          u32 lost_records;
>>>          u32 did:16, vid:16;
>>>          u64 first_tsc;
>>> -    } __attribute__((packed)) ed;
>>> +    } ed;
>> So why did you not strip this one in the previous patch?
> 
> My reading of a recent C spec draft would indicate that the compiler is
> perfectly at liberty to expand these :16 bitfields up 32 bits each, if
> it feels like doing so.

Which would then be better addressed by changing them both
to u16, dropping the bit fields altogether.

But I don't think the liberty given to a compiler is that wide: "An
implementation may allocate any addressable storage unit large
enough to hold a bitfield. If enough space remains, a bit-field
that immediately follows another bit-field in a structure shall be
packed into adjacent bits of the same unit."

I.e. the compiler has basically two choices: Use a 2-byte storage
unit for each of them, or use a 4-byte storage unit and put them
both in there. The end result is the same. What you're concerned
about can only happen when crossing storage unit boundaries.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel