Date: Wed, 17 Nov 2010 13:01:01 -0800 From: Garrett Cooper <gcooper@FreeBSD.org> 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 Subject: Re: Support for cc -m32 Message-ID: <AANLkTimuGZmKeEL=anOCkpLgSOwUiHpnRv3DG4SAspqT@mail.gmail.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 Wed, Nov 17, 2010 at 12:55 PM, Kostik Belousov <kostikbel@gmail.com> wro= te: > 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> =A0 = wrote: >> >>>>On 2010-08-30 22:09, Tijl Coosemans wrote: >> >>>>>On Monday 30 August 2010 20:36:36 M. Warner Losh wrote: >> >>>>>>:> =A0 =A0 http://people.freebsd.org/~tijl/cc-m32-1.diff >> >>This patch looks good. =A0I agree we should commit it right away. =A0I= can >> >>do the honors later today, or dim@ can. =A0I'm agnostic who does the p= ush. >> >Committed as r215439. >> > >> >>>>>>:> =A0 =A0 http://people.freebsd.org/~tijl/cc-m32-2.diff >> >>>>>>:> =A0 =A0 http://people.freebsd.org/~tijl/cc-m32-3.diff >> >>Now that we have tbemd in the tree, we should take a fresh look at the= se >> >>patches. =A0I'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: >> > >> > =A0 =A0 Install i386 headers on amd64. >> > >> > =A0 =A0 Machine specific headers for an architecture $arch are now ins= talled >> > =A0 =A0 under /usr/include/$arch. This means machine headers are alway= s in the >> > =A0 =A0 same location whether you are cross compiling or not. >> > >> > =A0 =A0 /usr/include/machine is a symlink to /usr/include/${MACHINE}. >> Yea, I don't like this (the sym link) at all because. =A0Machine headers >> wind up being wrong for amd64, so you have to resort to the following >> kludge. >> >cc-m32-3.diff: >> > =A0 =A0 Modify amd64 headers to include i386 headers when compiling 32= bit >> > =A0 =A0 code. >> > >> > =A0 =A0 All amd64 headers follow the following format: >> > >> > =A0 =A0 #ifndef _AMD64_HEADER_H_ >> > =A0 =A0 #define _AMD64_HEADER_H_ >> > >> > =A0 =A0 #ifdef __i386__ >> > =A0 =A0 #include<i386/header.h> >> > =A0 =A0 #else >> > >> > =A0 =A0 /* Amd64 declarations go here. */ >> > >> > =A0 =A0 #endif /* __i386__ */ >> > =A0 =A0 #endif /* !_AMD64_HEADER_H_ */ >> ... you wind up with stuff like this, which is also wrong. =A0It preclud= es >> 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 en= vi- ronment sets int, long and pointer to 32 bits and generates code that runs on any i386 system. The 64-bit environment sets int t= o 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). =A0That way, we wouldn't "forget" to add this code to new >> headers, etc. =A0The 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. =A0But that's a much larger >> patch. =A0I 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?AANLkTimuGZmKeEL=anOCkpLgSOwUiHpnRv3DG4SAspqT>