Date: Mon, 30 Aug 2010 12:36:36 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: tijl@coosemans.org Cc: freebsd-arch@freebsd.org Subject: Re: Support for cc -m32 Message-ID: <20100830.123636.59640143160044949.imp@bsdimp.com> In-Reply-To: <201008301731.19074.tijl@coosemans.org> References: <201007291718.12687.tijl@coosemans.org> <201008301731.19074.tijl@coosemans.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <201008301731.19074.tijl@coosemans.org>
Tijl Coosemans <tijl@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.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100830.123636.59640143160044949.imp>