Support for cc -m32

[Warner Losh]

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 :)
>
> 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.

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.

Warner
> -Nathan
>
>
>