Date: Wed, 17 Nov 2010 14:26:39 -0700 From: Warner Losh <imp@bsdimp.com> To: Kostik Belousov <kostikbel@gmail.com> Cc: Warner Losh <imp@FreeBSD.org>, Tijl Coosemans <tijl@coosemans.org>, Dimitry Andric <dim@FreeBSD.org>, freebsd-arch@FreeBSD.org, Garrett Cooper <gcooper@FreeBSD.org> Subject: Re: Support for cc -m32 Message-ID: <4CE4488F.5080305@bsdimp.com> In-Reply-To: <20101117205524.GX2392@deviant.kiev.zoral.com.ua> References: <201007291718.12687.tijl@coosemans.org> <AANLkTinA1D=fBfDznOaEufaskZxDHV=04%2BRjB3U=J6Hc@mail.gmail.com> <4CE417B3.3030102@bsdimp.com> <201011172058.05683.tijl@coosemans.org> <4CE43B7A.8030202@bsdimp.com> <20101117205524.GX2392@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CE4488F.5080305>