From owner-freebsd-arch@FreeBSD.ORG Thu Nov 18 13:14:41 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 B0B83106566B; Thu, 18 Nov 2010 13:14:41 +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 81CF18FC1B; Thu, 18 Nov 2010 13:14:41 +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 1BE6746B1A; Thu, 18 Nov 2010 08:14:41 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 196858A009; Thu, 18 Nov 2010 08:14:40 -0500 (EST) From: John Baldwin To: Warner Losh Date: Thu, 18 Nov 2010 07:48:22 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <201007291718.12687.tijl@coosemans.org> <201011171718.37798.jhb@freebsd.org> <4CE46602.9000303@bsdimp.com> In-Reply-To: <4CE46602.9000303@bsdimp.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201011180748.23094.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:40 -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: Garrett Cooper , Warner Losh , Tijl Coosemans , Dimitry Andric , freebsd-arch@freebsd.org 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:41 -0000 On Wednesday, November 17, 2010 6:32:18 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. My worry is a ./configure-like script for the native API (e.g. amd64) that will find an i386-only header in /usr/include/machine and fail to compile as a result. However, as I pointed out above, there really isn't an easy solution to this problem that covers all of the cases (even rewriting "machine" to "i386" doesn't cover many cases). I'm not really sure that 'if []' can even be solved, but it is one of the non-obvious considerations. > 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. I would prefer that to manually patching amd64 headers, certainly. -- John Baldwin