On 10/01/14 16:20, Chen Gang wrote:
> On 01/11/2014 12:02 AM, James Hogan wrote:
>> On 10/01/14 15:57, Chen Gang wrote:
>>> On 01/08/2014 11:01 PM, Chen Gang wrote:
>>>> On 01/06/2014 06:31 PM, James Hogan wrote:
>>>>> I suspect this is due to bad assumptions in the code. The metag ABI is
>>>>> unusual in padding the size of structs to a 32bit boundary even if all
>>>>> members are <32bit. This is actually permitted by the C standard but
>>>>> it's a bit of a pain. e.g.
>>>>>
>>>>> struct s {
>>>>> short x
>>>>> struct {
>>>>> short x[3];
>>>>> } y;
>>>>> short z;
>>>>> };
>>>>>
>>>>> on x86
>>>>> alignof(s::y) == 2
>>>>> s::y at offset 2
>>>>> sizeof(s::y) == 6
>>>>> s::z at offset 6+2 = 8
>>>>> sizeof(struct s) == 10
>>>>>
>>>>> but on metag
>>>>> alignof(s::y) == 4
>>>>> s::y at offset 4
>>>>> sizeof(s::y) == 8 (padding, this is what catches people out)
>>>>> s::z at offset 4+8 = 12
>>>>> sizeof(struct s) == 16 (and here too)
>>>>>
>>>>> Adding packed attribute on outer struct reduces sizeof(struct s) to 12
>>>>> on metag:
>>>>> alignof(s::y) == 4
>>>>> s::y at offset 2 (packed)
>>>>> sizeof(s::y) == 8 (still padded)
>>>>
>>>> In my memory, when packed(2), it breaks the C standard (although I am
>>>> not quit sure).
>>>>
>>>> And I guess, all C programmers will assume it will be 6 when within
>>>> pack(2) or pack(1).
>>>>
>>>>> s::z at offset 2+8 = 10
>>>>> sizeof(struct s) == 12 (packed)
>>>>>
>>>>> Also reduced to 12 if only inner struct is marked packed:
>>>>> alignof(s::y) == 2
>>>>> s::y at offset 2
>>>>> sizeof(s::y) == 6 (packed)
>>>>> s::z at offset 2+6 = 8
>>>>> sizeof(struct s) == 12 (still padded)
>>>>>
>>>>> Adding packed attribute on both outer and inner struct reduces
>>>>> sizeof(struct s) to 10 to match x86.
>>>>>
>>>>> Unfortunately it's years too late to change this ABI, so we're stuck
>>>>> with it.
>>>>>
>>>>
>>>> Unfortunately too, most using cases are related with API (the related
>>>> structure definition must be the same in binary data).
>>>>
>>>> I am sure there are still another ways to bypass this issue, but that
>>>> will make the code looks very strange (especially they are API).
>>>>
>>>> :-(
>>>>
>>>
>>> I guess most C programmers will use this way to describe protocol/data
>>> format, and keep compatible for it (since it is API).
>>>
>>> So even if it really does not break C standard, I still recommend our
>>> compiler to improve itself to support this features.
>>
>> The compiler cannot change this without breaking the ABI.
>>
>> If the structure describes a set-in-stone data layout (which it sounds
>> like it does since it asserts the size of it) then the correct fix is to
>> pack the structures in such a way as to guarantee the correct offsets
>> and sizes on all compliant compilers. Otherwise if it's just an internal
>> programming API it shouldn't be using compile time asserts to enforce
>> things that vary between ABIs.
>>
>
> OK, thanks, I guess your meaning is:
>
> struct s {
> short x;
> struct {
> short x[3];
> } y __attribute__ ((packed));
> short z;
> } __attribute__ ((packed));
>
> That will satisfy all of compilers (include metag), is it correct?
Yes, that's what I mean (although probably best to use the __packed
macro rather than __attribute__ ((packed)) ).
Cheers
James
--
To unsubscribe from this list: send the line "unsubscribe linux-metag" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
