Support for cc -m32

[Kostik Belousov]

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.

> 
> 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"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20101117/50c84deb/attachment.pgp