Build 32 bit binaries on amd64

[Dan McGregor]

My solution is certainly fairly hacky, I just took inspiration from
NetBSD. I wanted
to see if it could be done.  While I was there I did identify several
files that should be
common between i386 and amd64, such as exec.h.

Since reading your email I started looking at the x86 common code, and
have made some
more code common; specifically asm.h ans ucontext.h.  I'll be putting
that on github shortly.

Since it does look like tijl hasn't committed anything since March, I
would like to co-operate
and see what his plans were.  The idea of merging the i386 and amd64
headers into a
common area seems like a better idea to me.

Dan

On 21 August 2012 02:49, Konstantin Belousov <kostikbel at gmail.com> wrote:
> On Mon, Aug 20, 2012 at 08:32:41PM -0600, Dan McGregor wrote:
>> Hi.
>>
>> I've been working on porting compiler-rt/clang's support for address
>> sanitization (asan) to FreeBSD.  So far I have it building and it
>> appears to work properly, however the build system expects to be able
>> to build 32 bit binaries on amd64.
>>
>> amd64 doesn't include i386's machine/foo headers.  The included patch
>> is my proposed solution:
>>
>> Add i386 headers to /usr/include/i386, and in machine/foo.h, check if
>> it's a 32 bit build and include the appropriate header from i386.
>>
>> For example machine/ucontext.h will include i386/ucontext.h if
>> compiled with -m32.
>>
>> Thoughts?
>>
>> If anyone's curious about the compiler_rt port, I have it at
>> github.com/dannomac/compiler-rt on the branch named freebsd.
>
> There was a work by Tijl Coosemans in the similar, but somewhat less hacky
> direction. The headers are moved into sys/x86/include and unified as much
> as possible, while machine/ counterpart includes corresponding header
> from x86/include.
>
> I even lost track of how much more headers is left to convert. In fact,
> not all headers are equal, some are only useful for kernel or base system.
> Also, parts of the critically important headers do not live in machine/
> at all, e.g. the headers from libm.
>
> The work seems to be stale, do you want to cooperate with Tijl or continue ?