Date: Wed, 20 Feb 2013 19:34:40 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Nathan Whitehorn <nwhitehorn@freebsd.org> Cc: Damjan Jovanovic <damjan.jov@gmail.com>, Tijl Coosemans <tijl@coosemans.org>, freebsd-arch@freebsd.org Subject: Re: amd64 cc -m32 support and headers project branch Message-ID: <20130220173440.GH2598@kib.kiev.ua> In-Reply-To: <5124F908.3010901@freebsd.org> References: <201202061916.45998.tijl@coosemans.org> <20120223171210.GB79013@zim.MIT.EDU> <CAJm2B-m-Y==zHRe--xaDCULjUcL45we=K1cad4pncAdbRpGb3w@mail.gmail.com> <5124F908.3010901@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--OdQvBiqfLsaeimeB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2013 at 10:25:44AM -0600, Nathan Whitehorn wrote: > On 02/20/13 09:59, Damjan Jovanovic wrote: > > On Thu, Feb 23, 2012 at 7:12 PM, David Schultz <das@freebsd.org> wrote: > >> On Mon, Feb 06, 2012, Tijl Coosemans wrote: > >>> After a hiatus of almost a year I'd like to continue with merging i386 > >>> and amd64 headers to get "cc -m32" working on amd64. Previously I tri= ed > >>> to fix any problems with the headers first before merging, but this t= urned > >>> out to be a long tedious process. So, because lack of -m32 support is > >>> blocking other development I'd like to just merge a minimal set of > >>> headers without any macro/type definition changes or other > >>> reorganisations. The result will be similar to existing powerpc and m= ips > >>> headers which already support both 32 and 64 bit. > >>> > >>> When that's done I can create a development branch to work on the > >>> problems that have come up. Possible goals for such a branch are: > >>> > >>> - Fix inconsistencies such as types defined in sys/ and their limits > >>> in machine/. Also, sometimes the limits don't have the correct typ= e. > >>> - For types/limits defined under machine/ there is a lot of duplicati= on > >>> between architectures. Try to move some to sys/. > >>> - Try to make headers compiler agnostic; limit use of __attribute__, > >>> __builtin_* to a single file. > >>> - Maybe remove support for gcc 2.*. The oldest version in ports is 3.4 > >>> and I suspect some headers don't compile anymore with gcc 2.*. > >>> - Add support for new compiler attributes/built-ins. > >>> - Add missing POSIX prototypes, maybe commented out with /* UNIMPL ..= =2E */ > >>> or similar so they can be grepped. > >>> - The gcc ports currently patch some system headers where they think > >>> something is non-standard. These patched headers override the syst= em > >>> headers which means you have to rebuild these ports whenever you do > >>> installworld to make sure they contain the latest changes. Some he= aders > >>> are trivial to fix, others less so. > >>> > >>> > >>> If there are no objections, I'd like to start with the -m32 work in > >>> a week or so. > >> This sounds like it could degenerate into an error-prone ifdef > >> hell. Wouldn't it be much easier to just have a /usr/include32 > >> directory? > > But we don't have include32 for any other architecture. And how would > > it be implemented, compiler magic or #ifdef __LP64__ ..... #else > > #include <../include32/myself.h> #endif? > > > > On a possibly unrelated note, please let's try avoid the colossal fail > > that Debian's/Ubuntu's "multiarch" ideas has become, where they > > succeeded in separating 32 and 64 bit libraries into > > /usr/lib/i386-linux-gnu and /usr/lib/x86_64-linux-gnu, only to fail at > > doing the same for /usr/include, causing you to be able to parallel > > install the 32 and 64 bit binary versions of a package, but not the 32 > > and 64 bit development packages... > > _______________________________________________ > > 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" >=20 > I'll point out again that the #ifdef route is what we are currently=20 > doing, and have done for a couple years, for -m32 on PowerPC and MIPS.=20 > All the header files are actually shared for these architectures between= =20 > 32 and 64-bit versions (similar to sys/x86, but more complete) and it=20 > all works very well with a minimum of ugliness. I'd strongly encourage=20 > the same route for x86. Fully agreed. I will commit the last missing bits for the sys/ headers merge for x86 in a minute. The only significant piece left is the libm headers. --OdQvBiqfLsaeimeB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRJQkvAAoJEJDCuSvBvK1BpP0P/Ammqay2uipnvyPLM8r8BqqK oVk3WQorUcCpaJAcprai6xZQ5B83/tomxHRIosoPG9GX9A7WUFybWxJxWyEllir5 di8cJck8Iw4CGNUb3XWBpavO8ap6DcpFWPkPe5qM8NkcKAO4ldG1wvEfK+eCo9jQ dUmGkcAQMChSAFgZtbG8oHVBmmi5YAcUyOpUkmikkfRy+sYQlJRWZ3qpC0nC6OqK Cy+weImHZOwRKyRAUS0lUrVuuwqr6BKZbFSK/BY0S5yrAuFxCKkG2Ouqg/GBHb1M Uv6poW3wuUHyYDhYyE2jUBYO+eUG0Z9oM6Ju6Gjav4K9iInjgqIPqerXH5PTyY1t 7mDQ9DNL3Wam+dSGUZjX/BcFGgWWYf41mY1vhDMEP7hF5cYu/t4KKKSFOn0xScNR geMsIx9QTgKNyunCd2ZOG6uKjVInrpiVHrH3UcdFKr+oLAzdpGRifI1xdcRoApbG Rz0jZywM3M+g+kBne0d9FF7XVSSVBJGhC5KeYSpgNpUk+cpgWVFu/JO2O3s3QA2t sjjLogqAt5FYA5D0FMT6S2MKYrEFIB+d4vF4wnCJdQKhwngmYWccsCdy8F/Q0m/4 rSKtqSixcBlpUY/Xw4djzV/d5OMFVOlCLtLAzshN7oNOXvJ0xZhG3XOze6wWTbOJ 5JAp7s5JwDuFHMIXQfJ5 =NH+E -----END PGP SIGNATURE----- --OdQvBiqfLsaeimeB--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130220173440.GH2598>