From owner-freebsd-arch@FreeBSD.ORG Thu Nov 18 01:31:25 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 85CC1106566C; Thu, 18 Nov 2010 01:31:25 +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 523328FC0A; Thu, 18 Nov 2010 01:31:25 +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 <0LC20050848CFF00@smtpauth3.wiscmail.wisc.edu>; Wed, 17 Nov 2010 19:31:24 -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 <0LC200JDC489LK40@smtpauth3.wiscmail.wisc.edu>; Wed, 17 Nov 2010 19:31:23 -0600 (CST) Date: Wed, 17 Nov 2010 19:31:20 -0600 From: Nathan Whitehorn In-reply-to: <4CE46E94.7040405@bsdimp.com> To: Warner Losh Message-id: <6DDC2926-D359-4269-872A-0A8310AFC1AA@FreeBSD.org> X-Mailer: Apple Mail (2.936) X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.210.66.181 X-Spam-PmxInfo: Server=avs-11, Version=5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.11.18.12414, 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> <4CE46E94.7040405@bsdimp.com> Cc: Tijl Coosemans , Dimitry Andric , freebsd-arch@FreeBSD.org, John Baldwin , Garrett Cooper 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 01:31:25 -0000 On Nov 17, 2010, at 6:08 PM, Warner Losh wrote: > On 11/17/2010 16:52, 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. > There's still a number of these that must be in machine :) Right, I know -- my point was just that clearly amd64/include and i386/ include aren't actually that different, and that maybe they could be completely merged. MACHINE=x86? :P >> 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 > That's the idea. Automatically generate those and install them > into /usr/include. I think it is the least bad idea that we have, > since the more proper way has been rejected. Ah, OK. I guess my idea wasn't actually original :) > Actually, I suppose we could add -I/usr/include/32 to the command > line. David O'Brien said he was going to send me patches to do this, > but I've not seen them yet. Then we could install i386/include > into /usr/include/32/machine. This is as close as we can get to > having it done automatically. The nice part of this is that we can > make it generic between powerpc, mips and x86 if we wanted. Are you planning on a /sys/mips64? If not, this is still a special case just for x86. -Nathan