Date: Thu, 18 Nov 2010 07:50:55 -0500 From: John Baldwin <jhb@freebsd.org> To: Nathan Whitehorn <nwhitehorn@freebsd.org> Cc: Tijl Coosemans <tijl@coosemans.org>, Dimitry Andric <dim@freebsd.org>, Garrett Cooper <gcooper@freebsd.org>, freebsd-arch@freebsd.org, Warner Losh <imp@freebsd.org> Subject: Re: Support for cc -m32 Message-ID: <201011180750.55402.jhb@freebsd.org> In-Reply-To: <C96B2549-4BAE-4800-925D-57EA7DFD7733@freebsd.org> References: <201007291718.12687.tijl@coosemans.org> <4CE46602.9000303@bsdimp.com> <C96B2549-4BAE-4800-925D-57EA7DFD7733@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, November 17, 2010 6:52:40 pm 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.
Only a few of the headers have moved to x86/, and those were the easy
cases. There are a few more that could be merged (or possibly have
common bits in an x86/foo.h that both versions include).
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201011180750.55402.jhb>