Re: RFC: Add 32bit x86-64 support to binutils

["H. Peter Anvin" <hpa at zytor dot com>]

I believe it covers all cases *relevant for this particular situation* (unlike, say, MIPS) and that any deviation is a bug which can and should be fixed.

"David Daney" <ddaney@caviumnetworks.com> wrote:

>On 12/30/2010 12:12 PM, H. Peter Anvin wrote:
>> On 12/30/2010 11:34 AM, David Daney wrote:
>>>
>>> My suggestion:  Since people already spend a great deal of effort
>>> maintaining the existing i386 compatible Linux syscall
>infrastructure,
>>> make your new 32-bit x86-64 Linux syscall ABI identical to the
>existing
>>> i386 syscall ABI.  This means that the psABI must use the same size
>and
>>> alignment rules for in-memory structures as the i386 does.
>>>
>>
>> No, it doesn't.  It just means it need to do so *for the types used
>by
>> the kernel*.  The kernel uses types like __u64, which would indeed
>have
>> to be declared aligned(4).
>>
>
>Some legacy interfaces don't use fixed width types.  There almost 
>certainly are some ioctls that don't use your fancy __u64.
>
>Then there are things like ppoll() that take a pointer to:
>
>            struct timespec {
>                long    tv_sec;         /* seconds */
>                long    tv_nsec;        /* nanoseconds */
>            };
>
>There are no fields in there that are controlled by __u64 either. 
>Admittedly this case might not differ between the two 32-bit ABIs, but 
>it shows that __u64/__u32 are not universally used in the Linux syscall
>
>ABIs.
>
>If you are happy with potential memory layout differences between the 
>two 32-bit ABIs, then don't specify that they are the same.  But don't 
>claim that use of __u64/__u32 covers all cases.
>
>David Daney

-- 
Sent from my mobile phone.  Please pardon any lack of formatting.