Support for cc -m32

[Nathan Whitehorn]

On Nov 17, 2010, at 6:08 PM, Warner Losh wrote:

> On 11/17/2010 16:52, Nathan Whitehorn wrote:
>>
>> On Nov 17, 2010, at 5:32 PM, Warner Losh wrote:
>>
>>> On 11/17/2010 15:18, John Baldwin wrote:
>>>> On Wednesday, November 17, 2010 2:57:51 pm Tijl Coosemans wrote:
>>>>> cc-m32-3.diff:
>>>>>    Modify amd64 headers to include i386 headers when compiling  
>>>>> 32 bit code.
>>>>>
>>>>>    All amd64 headers follow the following format:
>>>>>
>>>>>    #ifndef _AMD64_HEADER_H_
>>>>>    #define _AMD64_HEADER_H_
>>>>>
>>>>>    #ifdef __i386__
>>>>>    #include<i386/header.h>
>>>>>    #else
>>>>>
>>>>>    /* Amd64 declarations go here. */
>>>>>
>>>>>    #endif /* __i386__ */
>>>>>    #endif /* !_AMD64_HEADER_H_ */
>>>> I find this to be really ugly, and error prone (since it is a  
>>>> manual process).
>>>> I'd prefer something that autogenerated headers in /usr/include/ 
>>>> machine that
>>>> #include the appropriate version similar to what Warner suggested.
>>>>
>>>> However, one issue with that approach (and this one) are headers  
>>>> that only
>>>> exist for one platform.  The end result would be that that header  
>>>> would now
>>>> exist for both platforms (in that if you do 'if [ -r
>>>> /usr/include/machine/foo.h ]' it will be true).  We can make it  
>>>> #error or
>>>> otherwise fail (by including a non-existing file for example),  
>>>> but if there
>>>> was some way to have cc -m32 "magically" substitute "i386/" for  
>>>> "machine",
>>>> that is what I would most prefer.  (This has problems too in that  
>>>> #include
>>>> <machine/foo.h>  would work with -m32 even though /usr/include/ 
>>>> machine/foo.h
>>>> doesn't exist, but /usr/include/i386/foo.h does.
>>> "magically" converting machine -> i386 requires cpp hacking.
>>>
>>> However, the if [] test is beyond the scope of the API that we  
>>> support.  Scripts that use -m32 will have to cope with other issues.
>>>
>>> We could 'solve' this by having an /usr/include32, but even that  
>>> still isn't complete.
>>>
>>> I contend that the least bad solution is to auto generate the  
>>> machine directory from the sys/{i386,amd64}/include.  If we do  
>>> that, we could implement -m64 on i386 too, but that needs a lot  
>>> more infrastructure.
>>
>> The other way of solving this, which continues to work very well on  
>> powerpc64, is to have the machine/ stuff be identical for the two  
>> platforms (which, as far as I can tell, really are the same  
>> platform, but with a different ABI) and to use appropriate #ifdefs  
>> to select the right things. I would imagine, based on the continued  
>> exodus of these headers to x86/ anyway, that the differences are  
>> not enormously large. They certainly were not for PPC.
> There's still a number of these that must be in machine :)

Right, I know -- my point was just that clearly amd64/include and i386/ 
include aren't actually that different, and that maybe they could be  
completely merged. MACHINE=x86? :P

>> This could be done either with piece-by-piece modifications of the  
>> header files, as was done for PPC, or (perhaps automatically)  
>> install some ugly stub headers that look like
>> #ifdef __LP64__
>> #include <amd64/stuff.h>
>> #else
>> #include <i386/stuff.h>
>> #endif
> That's the idea.  Automatically generate those and install them  
> into /usr/include.  I think it is the least bad idea that we have,  
> since the more proper way has been rejected.

Ah, OK. I guess my idea wasn't actually original :)

> Actually, I suppose we could add -I/usr/include/32 to the command  
> line. David O'Brien said he was going to send me patches to do this,  
> but I've not seen them yet.  Then we could install i386/include  
> into /usr/include/32/machine.  This is as close as we can get to  
> having it done automatically.  The nice part of this is that we can  
> make it generic between powerpc, mips and x86 if we wanted.

Are you planning on a /sys/mips64? If not, this is still a special  
case just for x86.
-Nathan