Support for cc -m32

Thu Nov 18 17:55:37 UTC 2010

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 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.
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.

> 
> 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: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20101118/6dda8b20/attachment.pgp