RFC: Add 32bit x86-64 support to binutils

[David Daney]

On 12/30/2010 12:28 PM, H.J. Lu wrote:
> On Thu, Dec 30, 2010 at 12:27 PM, 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.
>
> We can put a syscall wrapper to translate it.
>

Of course you can.

But you are starting with a blank slate, you should be asking yourself 
why you would want to.

What is your objective here?  Is it:

1) Fastest time to a relatively bug free useful system?

or

2) Purity of ABI design?


What would the performance penalty be for identical structure layout 
between the two 32-bit ABIs?

Really I don't care one way or the other.  The necessity of syscall 
wrappers is actually probably beneficial to me.  It will create a 
greater future employment demand for people with the necessary skills to 
write them.

David Daney