Date: Thu, 18 Nov 2010 19:55:29 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Tijl Coosemans <tijl@coosemans.org> Cc: Garrett Cooper <gcooper@freebsd.org>, Dimitry Andric <dim@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: Support for cc -m32 Message-ID: <20101118175529.GK2392@deviant.kiev.zoral.com.ua> In-Reply-To: <201011181843.23185.tijl@coosemans.org> References: <201007291718.12687.tijl@coosemans.org> <201011172058.05683.tijl@coosemans.org> <4CE43B7A.8030202@bsdimp.com> <201011181843.23185.tijl@coosemans.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--4USs1MzHaHCyIKuP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 18, 2010 at 06:43:15PM +0100, Tijl Coosemans wrote: > On Wednesday 17 November 2010 21:30:50 Warner Losh wrote: > > On 11/17/2010 12:57, Tijl Coosemans wrote: > >>>>>>> :> http://people.freebsd.org/~tijl/cc-m32-2.diff > >>>>>>> :> http://people.freebsd.org/~tijl/cc-m32-3.diff > >> 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 instal= led > >> under /usr/include/$arch. This means machine headers are always i= n 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= =20 > > wind up being wrong for amd64, so you have to resort to the following= =20 > > kludge. > > > >> cc-m32-3.diff: > >> Modify amd64 headers to include i386 headers when compiling 32 bi= t 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 preclude= s=20 > > implementing -mpc98 for building on amd64, for example. >=20 > Maybe I was wrong to call it cross compilation because in this case the > resulting binaries also run on the host system. The patches are meant > to support only this particular feature of amd64 to make it possible to > build emulators/wine on amd64 for instance. I don't think we should > ever support general cross compilation like compiling for pc98 on > amd64 or for amd64 on i386. Users have to install a real cross compiler > with its own include (and lib) directories for that anyway. In this > case however the system compiler already compiles and links 32 bit > code. It just uses the wrong types at the moment. >=20 > To fix that there are basically two approaches: change the compiler or > change the headers. Personally I prefer the latter because the former > would have to be repeated for every compiler. >=20 > And so that's what the patches do. They add 32 bit types to the amd64 > headers and reuse the i386 headers for that. I admit they currently > take the blunt shotgun approach by modifying (almost) all amd64 headers > in the same way. This could be refined somewhat header by header. >=20 > Some headers can be moved to x86 and the existing header replaced by > a stub that includes the x86 header such as has been done for > apm_bios.h. The patch doesn't modify that one. >=20 > Some other headers don't conflict and can be merged and moved to x86. > Some can be merged with only a few changes. For instance, some i386 > headers already define some types as 64 bit in case of PAE. You could > add "|| defined(__x86_64__)" to that. If the differences between the > headers are small, they can be grouped and put behind #ifdef __i386__ > ... #else ... #endif. >=20 > This seems to be the approach taken by NetBSD. Most headers have been > merged and moved to x86. Only some of the amd64 headers have #ifdef > __x86_64__ ... #else #include <i386/...> #endif. If I understand their > Makefiles correctly /usr/include/machine is also a symlink. On OpenBSD > as well. The patches would bring us more in line here. >=20 > > I'd rather we install {i386,amd64} into /usr/include/ and have machine= =20 > > be generated from those two directories (or three, if we supported=20 > > -mpc98 ever). That way, we wouldn't "forget" to add this code to new= =20 > > headers, etc. The generated code would be trivial: > >=20 > > #ifdef __i386__ > > #include <i386/foo.h> > > #else > > #include <amd64/foo.h> > > #endif >=20 > I'm not entirely opposed to this, but what would this look like on > other architectures? For instance, will i386 headers be available under > /usr/include/i386 on a i386 system as well? It's not a requirement, but > still a nice side effect of the current patches. >=20 > Also, this would get in the way of headers that have been moved to x86. > They wouldn't need this. >=20 > I also don't think forgetting to add 32 bit support to new amd64 > headers will be a significant problem. There haven't been any new > headers in years. Additional important note is that only machine/ headers really needed by userland compilation must be cared about. The -m32 feature is only to support compilation of usermode programs, not kernel modules. >=20 > In the end it's just another machine specific feature that in my > opinion belongs in machine specific headers. The difference with other > machine specific features is of course that isn't isolated to one > header, but rather spread over all of them. That makes it look > impressive, but it isn't actually very complicated. >=20 > So, I'm open to further comments (of course), but I still think the > patches take the right approach. --4USs1MzHaHCyIKuP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzlaJAACgkQC3+MBN1Mb4jFywCgs6M0lfh+HTPKTeaduzXOP8/x va4AnRrf8uRAu3quyHynmG44ATeH/Kls =OVfC -----END PGP SIGNATURE----- --4USs1MzHaHCyIKuP--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101118175529.GK2392>