Support for cc -m32

[Warner Losh]

On 11/17/2010 13:55, Kostik Belousov wrote:
> On Wed, Nov 17, 2010 at 01:30:50PM -0700, Warner Losh wrote:
>> 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.
> Isn't the ABI on pc98 port identical to i386 ABI ? If yes, I do not
> see a reason to want -mpc98.
The syscall interface is identical.  However, there's a number of 
differences in the drivers that are hidden behind machine/foo.h, 
however.  Otherwise, we wouldn't bother with two different sets of headers.
> -m32 is a way to compile for the "32bit usermode twin" of the current
> architecture only, and never intended to be a cross-compilation
> environment.
Yea, I didn't want to preclude the possibility of a -mpc98, but I do 
understand that it would be a bit of a kludge.
>> 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
>>
>> _______________________________________________
>> freebsd-arch at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"