Support for cc -m32

[Warner Losh]

On 11/17/2010 12:57, Tijl Coosemans wrote:
> On Wednesday 17 November 2010 18:58:11 Warner Losh wrote:
>> On 11/17/2010 10:21, Garrett Cooper wrote:
>>> On Wed, Nov 17, 2010 at 4:19 AM, Dimitry Andric<dim at freebsd.org>   wrote:
>>>> On 2010-08-30 22:09, Tijl Coosemans wrote:
>>>>> On Monday 30 August 2010 20:36:36 M. Warner Losh wrote:
>>>>>> :>     http://people.freebsd.org/~tijl/cc-m32-1.diff
>> This patch looks good.  I agree we should commit it right away.  I can
>> do the honors later today, or dim@ can.  I'm agnostic who does the push.
> Committed as r215439.
>
>>>>>> :>     http://people.freebsd.org/~tijl/cc-m32-2.diff
>>>>>> :>     http://people.freebsd.org/~tijl/cc-m32-3.diff
>> Now that we have tbemd in the tree, we should take a fresh look at these
>> patches.  I'll try to look at these later today as well.
> I've updated them to today's CURRENT. They're a bit smaller now because
> some amd64 headers have been moved to x86. This also solved the problem
> with the kdump build.
>
> Here are the commit logs:
>
> cc-m32-2.diff:
>
>      Install i386 headers on amd64.
>
>      Machine specific headers for an architecture $arch are now installed
>      under /usr/include/$arch. This means machine headers are always in the
>      same location whether you are cross compiling or not.
>
>      /usr/include/machine is a symlink to /usr/include/${MACHINE}.
Yea, I don't like this (the sym link) at all because.  Machine headers 
wind up being wrong for amd64, so you have to resort to the following 
kludge.
> 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_ */
... you wind up with stuff like this, which is also wrong.  It precludes 
implementing -mpc98 for building on amd64, for example.

I'd rather we install {i386,amd64} into /usr/include/ and have machine 
be generated from those two directories (or three, if we supported 
-mpc98 ever).  That way, we wouldn't "forget" to add this code to new 
headers, etc.  The generated code would be trivial:

#ifdef __i386__
#include <i386/foo.h>
#else
#include <amd64/foo.h>
#endif

(which is extensible to support pc98 too, if we wanted to add -mpc98).

Of course, I'd really rather we have a /usr/include32 which has a 
separate, pristine copy of everything in it.  But that's a much larger 
patch.  I think it would be cleaner, but there seems to be universal 
resistance to this sort of scheme.

Warner