Support for cc -m32

[Tijl Coosemans]

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 installed
>>      under /usr/include/$arch. This means machine headers are always in 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 
> wind up being wrong for amd64, so you have to resort to the following 
> kludge.
>
>> cc-m32-3.diff:
>>      Modify amd64 headers to include i386 headers when compiling 32 bit 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 precludes 
> implementing -mpc98 for building on amd64, for example.

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.

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.

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.

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.

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.

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.

> 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).  That way, we wouldn't "forget" to add this code to new 
> headers, etc.  The generated code would be trivial:
> 
> #ifdef __i386__
> #include <i386/foo.h>
> #else
> #include <amd64/foo.h>
> #endif

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.

Also, this would get in the way of headers that have been moved to x86.
They wouldn't need this.

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.

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.

So, I'm open to further comments (of course), but I still think the
patches take the right approach.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20101118/43d8868a/attachment.pgp