Support for cc -m32

[Tijl Coosemans]

On Monday 30 August 2010 20:36:36 M. Warner Losh wrote:
> In message: <201008301731.19074.tijl at coosemans.org>
>             Tijl Coosemans <tijl at coosemans.org> writes:
> : On Thursday 29 July 2010 17:18:03 Tijl Coosemans wrote:
> : > I've put the initial version of some patches online to support cross
> : > compilation of 32 bit binaries on amd64. It's modelled after how NetBSD
> : > does this.
> : > 
> : > With these patches something like "cc -m32 -o test test.c -pthread -lm"
> : > generates a program that runs on FreeBSD/i386.
> : > 
> : > http://people.freebsd.org/~tijl/cc-m32-1.diff
> : > http://people.freebsd.org/~tijl/cc-m32-2.diff
> : > http://people.freebsd.org/~tijl/cc-m32-3.diff
> : > 
> : > *cc-m32-1.diff* : Let ld and cc find 32 bit libraries.
> : > 
> : > *cc-m32-2.diff* : Install i386 headers on amd64.
> : > 
> : > With this patch headers for a particular $arch are always installed
> : > under /usr/include/$arch and /usr/include/machine becomes a symlink.
> : > 
> : > A question I have here is how best to clean up the old machine
> : > directory. The patch currently uses 'rm -rf'.
> : > 
> : > Another problem I encountered was that during the build of
> : > usr.bin/kdump all headers are searched for definitions of ioctl
> : > requests and a C source code file is generated that includes all those
> : > headers. This fails when both i386 and amd64 headers are installed
> : > because they can't both be included at the same time. For now the patch
> : > simply blacklists /usr/include/i386, but actually all $arch should be
> : > excluded. The ioctl requests can still be found through the machine
> : > symlink. If someone has a better idea...
> : > 
> : > *cc-m32-3.diff* : Modify amd64 headers to include i386 headers when
> : >                   __i386__ is defined.
> : > 
> : > This patch modifies the amd64 headers to follow this format:
> : > 
> : >   #ifndef _AMD64_HEADER_H
> : >   #define _AMD64_HEADER_H
> : > 
> : >   #ifdef __i386__
> : >   #include <i386/header.h>
> : >   #else
> : > 
> : >   ...
> : > 
> : >   #endif /* __i386__ */
> : >   #endif /* !_AMD64_HEADER_H */
> : > 
> : > This way including <machine/header.h> works for -m32. There are a few
> : > i386 headers which don't exist for amd64:
> : > 
> : > apm_segments.h
> : > bootinfo.h
> : > cserial.h
> : > elan_mmcr.h
> : > if_wl_wavelan.h
> : > ioctl_bt848.h
> : > ioctl_meteor.h
> : > npx.h
> : > pcaudioio.h
> : > pcb_ext.h
> : > perfmon.h
> : > privatespace.h
> : > smapi.h
> : > speaker.h
> : > vm86.h
> : > xbox.h
> : > 
> : > Theoretically a dummy amd64 header should be created for each of them
> : > that just includes the i386 header. The patch does this for npx.h. The
> : > other headers seem to be really i386 specific or even outdated. If it
> : > were ever necessary to cross-compile code that uses them, it would be
> : > easy to modify that code to directly include <i386/header.h>.
> : > 
> : > 
> : > Feel free to test the patches and to comment on any part of them.
> : 
> : I'd like to move forward with this now. I've rebased the patches above
> : against today's CURRENT. If there are no further objections I'd like to
> : commit them a few days from now, let's say Saturday.
> 
> I have been trying to get the tbemd patches into the tree and these
> patches conflict with them.  Can we hold off until I get them in?
> I've had to rebase things myself a dozen times and each time I've only
> been able to get part of the patches in...
> 
> I still have the objections from before, but I'll take a look at the
> new patches to see if they are addressed or not.

Ok, no problem.
-------------- 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/20100830/6bdfde58/attachment.pgp