From owner-freebsd-arch@FreeBSD.ORG Thu Nov 18 00:52:50 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 00D2D106567A; Thu, 18 Nov 2010 00:52:50 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by mx1.freebsd.org (Postfix) with ESMTP id C25F08FC18; Thu, 18 Nov 2010 00:52:49 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed; delsp=yes Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LC100J0GZNZUP00@smtpauth3.wiscmail.wisc.edu>; Wed, 17 Nov 2010 17:52:47 -0600 (CST) Received: from [10.0.2.97] ([unknown] [76.210.66.181]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LC100J7FZNSLK00@smtpauth3.wiscmail.wisc.edu>; Wed, 17 Nov 2010 17:52:42 -0600 (CST) Date: Wed, 17 Nov 2010 17:52:40 -0600 From: Nathan Whitehorn In-reply-to: <4CE46602.9000303@bsdimp.com> To: Warner Losh Message-id: X-Mailer: Apple Mail (2.936) X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.210.66.181 X-Spam-PmxInfo: Server=avs-10, Version=5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.11.17.233321, SenderIP=76.210.66.181 References: <201007291718.12687.tijl@coosemans.org> <4CE417B3.3030102@bsdimp.com> <201011172058.05683.tijl@coosemans.org> <201011171718.37798.jhb@freebsd.org> <4CE46602.9000303@bsdimp.com> 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 00:52:50 -0000 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. This could be done either with piece-by-piece modifications of the header files, as was done for PPC, or (perhaps automatically) install some ugly stub headers that look like #ifdef __LP64__ #include #else #include #endif -Nathan