From owner-freebsd-arch@FreeBSD.ORG Thu Nov 18 13:14:42 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEE54106566C; Thu, 18 Nov 2010 13:14:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8588E8FC1C; Thu, 18 Nov 2010 13:14:42 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0A5C346B53; Thu, 18 Nov 2010 08:14:42 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 37C068A01D; Thu, 18 Nov 2010 08:14:41 -0500 (EST) From: John Baldwin To: Nathan Whitehorn Date: Thu, 18 Nov 2010 07:50:55 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <201007291718.12687.tijl@coosemans.org> <4CE46602.9000303@bsdimp.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011180750.55402.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 18 Nov 2010 08:14:41 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Tijl Coosemans , Dimitry Andric , Garrett Cooper , freebsd-arch@freebsd.org, Warner Losh Subject: Re: Support for cc -m32 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 13:14:43 -0000 On Wednesday, November 17, 2010 6:52:40 pm Nathan Whitehorn wrote: > > On Nov 17, 2010, at 5:32 PM, Warner Losh wrote: > > > On 11/17/2010 15:18, John Baldwin wrote: > >> On Wednesday, November 17, 2010 2:57:51 pm Tijl Coosemans wrote: > >>> cc-m32-3.diff: > >>> Modify amd64 headers to include i386 headers when compiling 32 > >>> bit code. > >>> > >>> All amd64 headers follow the following format: > >>> > >>> #ifndef _AMD64_HEADER_H_ > >>> #define _AMD64_HEADER_H_ > >>> > >>> #ifdef __i386__ > >>> #include > >>> #else > >>> > >>> /* Amd64 declarations go here. */ > >>> > >>> #endif /* __i386__ */ > >>> #endif /* !_AMD64_HEADER_H_ */ > >> I find this to be really ugly, and error prone (since it is a > >> manual process). > >> I'd prefer something that autogenerated headers in /usr/include/ > >> machine that > >> #include the appropriate version similar to what Warner suggested. > >> > >> However, one issue with that approach (and this one) are headers > >> that only > >> exist for one platform. The end result would be that that header > >> would now > >> exist for both platforms (in that if you do 'if [ -r > >> /usr/include/machine/foo.h ]' it will be true). We can make it > >> #error or > >> otherwise fail (by including a non-existing file for example), but > >> if there > >> was some way to have cc -m32 "magically" substitute "i386/" for > >> "machine", > >> that is what I would most prefer. (This has problems too in that > >> #include > >> would work with -m32 even though /usr/include/ > >> machine/foo.h > >> doesn't exist, but /usr/include/i386/foo.h does. > > "magically" converting machine -> i386 requires cpp hacking. > > > > However, the if [] test is beyond the scope of the API that we > > support. Scripts that use -m32 will have to cope with other issues. > > > > We could 'solve' this by having an /usr/include32, but even that > > still isn't complete. > > > > I contend that the least bad solution is to auto generate the > > machine directory from the sys/{i386,amd64}/include. If we do that, > > we could implement -m64 on i386 too, but that needs a lot more > > infrastructure. > > The other way of solving this, which continues to work very well on > powerpc64, is to have the machine/ stuff be identical for the two > platforms (which, as far as I can tell, really are the same platform, > but with a different ABI) and to use appropriate #ifdefs to select the > right things. I would imagine, based on the continued exodus of these > headers to x86/ anyway, that the differences are not enormously large. > They certainly were not for PPC. Only a few of the headers have moved to x86/, and those were the easy cases. There are a few more that could be merged (or possibly have common bits in an x86/foo.h that both versions include). -- John Baldwin