From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 22 17:03:01 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3613C1065689 for ; Wed, 22 Aug 2012 17:03:01 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id CFACF8FC21 for ; Wed, 22 Aug 2012 17:03:00 +0000 (UTC) Received: by yenl7 with SMTP id l7so1039879yen.13 for ; Wed, 22 Aug 2012 10:03:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Wj34K4q7YyOGXku0lKk6ZhsDYukgFPNXYgzxyU5n1E4=; b=jyLU65WCDSB0kqg0nejXq+Zw45S+DPl2CqmV9/+WfTHFxX8e2FlHrlN6pRBv85pOFE fI505xZ/gR49GCcAKlOdCb8Q7Xi0qgBGXBR+WAtXM+ujkLWuuSoDUc1nXMEGRPiAiaep 7aJGdqzu/h+NGC80F1ukCQEI4CQ4wHfs7sNmuv/sxrGxi8qKSdG8sVwYLxv28prsMtnz h/+0Zw/zl4DwlRP/fD7MCWGq9ahYQm7RCobHT9RzaVo8JlSOBt8fkw043ZSJ5Cgj/NwO ybkA3T6HoyUr2Q6KlquJginSYwUifSgtUKNFD+MqP/VN3rRexyHTULZzexpTw6iVrwcA 9l1g== Received: by 10.60.172.15 with SMTP id ay15mr1876150oec.64.1345654980026; Wed, 22 Aug 2012 10:03:00 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id el2sm36876obc.8.2012.08.22.10.02.58 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Aug 2012 10:02:59 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <5033B89C.7070201@freebsd.org> Date: Wed, 22 Aug 2012 11:02:56 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120821084930.GM33100@deviant.kiev.zoral.com.ua> <201208210944.31001.jhb@freebsd.org> <5033B89C.7070201@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQly4WOLLO6PH37c/0WjG6BTjjF5+LgpFhEm1RnowGAHYe3dVmtBH++Ps2uNGpkYjJJv4u/g Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, tijl@freebsd.org, Dan McGregor Subject: Re: Build 32 bit binaries on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 17:03:01 -0000 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=