From owner-freebsd-arch@FreeBSD.ORG Wed Feb 20 17:34:47 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EEC31DA0; Wed, 20 Feb 2013 17:34:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 5CCA7677; Wed, 20 Feb 2013 17:34:47 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1KHYeUm085980; Wed, 20 Feb 2013 19:34:40 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1KHYeUm085980 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1KHYe10085979; Wed, 20 Feb 2013 19:34:40 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 20 Feb 2013 19:34:40 +0200 From: Konstantin Belousov To: Nathan Whitehorn Subject: Re: amd64 cc -m32 support and headers project branch Message-ID: <20130220173440.GH2598@kib.kiev.ua> References: <201202061916.45998.tijl@coosemans.org> <20120223171210.GB79013@zim.MIT.EDU> <5124F908.3010901@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OdQvBiqfLsaeimeB" Content-Disposition: inline In-Reply-To: <5124F908.3010901@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Damjan Jovanovic , Tijl Coosemans , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 17:34:48 -0000 --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 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--