Support for cc -m32

[Garrett Cooper]

On Wed, Nov 17, 2010 at 12:55 PM, Kostik Belousov <kostikbel at gmail.com> 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.
>
> -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.

Hmmm... it seems like the manpage disagrees:

       -m32
       -m64
           Generate code for a 32-bit or 64-bit environment.  The 32-bit envi-
           ronment sets int, long and pointer to 32 bits and generates code
           that runs on any i386 system.  The 64-bit environment sets int to
           32 bits and long and pointer to 64 bits and generates code for
           AMD's x86-64 architecture. For darwin only the -m64 option turns
           off the -fno-pic and -mdynamic-no-pic options.

Then again it doesn't actually state what will happen after the fact
in the linking process.

>> 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"
>