Date: Wed, 22 Aug 2012 11:02:56 -0600 From: Warner Losh <imp@bsdimp.com> To: Nathan Whitehorn <nwhitehorn@freebsd.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, freebsd-hackers@freebsd.org, tijl@freebsd.org, Dan McGregor <dan.mcgregor@usask.ca> Subject: Re: Build 32 bit binaries on amd64 Message-ID: <AE9FF660-543A-4374-BD20-33788ED2DFB0@bsdimp.com> In-Reply-To: <5033B89C.7070201@freebsd.org> References: <CACS%2B7ZQSSoxqY8cNDa=uM-o5NJmXBb3WYTZ7iNDK_nNjjughUg@mail.gmail.com> <20120821084930.GM33100@deviant.kiev.zoral.com.ua> <201208210944.31001.jhb@freebsd.org> <5033B89C.7070201@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Aug 21, 2012, at 10:34 AM, Nathan Whitehorn wrote: > On 08/21/12 08:44, John Baldwin wrote: >> On Tuesday, August 21, 2012 4:49:30 am Konstantin Belousov wrote: >>> On Mon, Aug 20, 2012 at 08:32:41PM -0600, Dan McGregor wrote: >>>> Hi. >>>>=20 >>>> 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. >>>>=20 >>>> amd64 doesn't include i386's machine/foo headers. The included = patch >>>> is my proposed solution: >>>>=20 >>>> 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. >>>>=20 >>>> For example machine/ucontext.h will include i386/ucontext.h if >>>> compiled with -m32. >>>>=20 >>>> Thoughts? >>>>=20 >>>> 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. >>>=20 >>> 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. >>>=20 >>> The work seems to be stale, do you want to cooperate with Tijl or = continue ? >> I think we should probably follow Tijl's model since we are on that = path. >> I originally preferred the /usr/include/i386 approach, but have come = around >> to Tjil's approach instead. >>=20 >=20 > I just wanted to add that the unified 32/64 header route is where we = went on PowerPC (and MIPS?) and it works very well for -m32. I don't know if mips has full -m32 support yet, but we do have one set = of headers there and that works for all mips modes. We also have one = set of headers for ARM too, but that's all ISA related, not 32 vs 64 = related... yet. The original i386 headers were copied to amd64 so they could be cleansed = of all the historical baggage from i386. This turned out to be a good = approach in many parts of the code, but not such a good idea for the = headers. I'm glad to see we're finally cleaning this up. Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AE9FF660-543A-4374-BD20-33788ED2DFB0>