amd64 cc -m32 support and headers project branch

[Konstantin Belousov]

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 at 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 tried
> >>> to fix any problems with the headers first before merging, but this turned
> >>> 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 mips
> >>> 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 type.
> >>> - For types/limits defined under machine/ there is a lot of duplication
> >>>    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 ... */
> >>>    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 system
> >>>    headers which means you have to rebuild these ports whenever you do
> >>>    installworld to make sure they contain the latest changes. Some headers
> >>>    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 at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> > To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
> 
> I'll point out again that the #ifdef route is what we are currently 
> doing, and have done for a couple years, for -m32 on PowerPC and MIPS. 
> All the header files are actually shared for these architectures between 
> 32 and 64-bit versions (similar to sys/x86, but more complete) and it 
> all works very well with a minimum of ugliness. I'd strongly encourage 
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20130220/22be33fe/attachment.sig>