From owner-freebsd-arch@FreeBSD.ORG Wed Nov 17 21:01:04 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 503631065670; Wed, 17 Nov 2010 21:01:04 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 83DD68FC1A; Wed, 17 Nov 2010 21:01:03 +0000 (UTC) Received: by wwd20 with SMTP id 20so2421045wwd.31 for ; Wed, 17 Nov 2010 13:01:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=9SXwC4bs0Q3LkmVG/8jA7od+18bl5MTrYAFJHKu6PWQ=; b=i19v8hz6CrGypT+FQIiCxOdnJm6fFg7b7YzhLEvbAk75pKRGyhRGksFJ9pXenkA5Od JseqQNsO+eHGP21HBn6hSUDW//Qf5BC9zk8ciPtjMKnHtcp/qCfaRLCas+IgUiVRnkjV OhoLTn63x9WE5RZuMmyia2c3yZt2SiHS0h9GI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=X+kpmye2KZaM4PBdOybuVOSgHgb+IebyKzXGERqPOfxY5EnFkP/iOjAAABEDT6/zIh AJgxhIp3S4K5sE2y/XzxLpISMmlVFFTWLz0dcTs+JYF3DehHzgrvwv6r7LOTc0S8Xyv2 Pq+BvBigteCWizs8S3e9/80JMNQdu51cI/8+Y= MIME-Version: 1.0 Received: by 10.216.175.18 with SMTP id y18mr9515634wel.30.1290027661379; Wed, 17 Nov 2010 13:01:01 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Wed, 17 Nov 2010 13:01:01 -0800 (PST) In-Reply-To: <20101117205524.GX2392@deviant.kiev.zoral.com.ua> References: <201007291718.12687.tijl@coosemans.org> <4CE417B3.3030102@bsdimp.com> <201011172058.05683.tijl@coosemans.org> <4CE43B7A.8030202@bsdimp.com> <20101117205524.GX2392@deviant.kiev.zoral.com.ua> Date: Wed, 17 Nov 2010 13:01:01 -0800 X-Google-Sender-Auth: 6rt_3wh8e53f3LZUxnu8qY3ZFZc Message-ID: From: Garrett Cooper To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 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: Wed, 17 Nov 2010 21:01:04 -0000 On Wed, Nov 17, 2010 at 12:55 PM, Kostik Belousov wro= te: > On Wed, Nov 17, 2010 at 01:30:50PM -0700, Warner Losh wrote: >> On 11/17/2010 12:57, Tijl Coosemans wrote: >> >On Wednesday 17 November 2010 18:58:11 Warner Losh wrote: >> >>On 11/17/2010 10:21, Garrett Cooper wrote: >> >>>On Wed, Nov 17, 2010 at 4:19 AM, Dimitry Andric =A0 = wrote: >> >>>>On 2010-08-30 22:09, Tijl Coosemans wrote: >> >>>>>On Monday 30 August 2010 20:36:36 M. Warner Losh wrote: >> >>>>>>:> =A0 =A0 http://people.freebsd.org/~tijl/cc-m32-1.diff >> >>This patch looks good. =A0I agree we should commit it right away. =A0I= can >> >>do the honors later today, or dim@ can. =A0I'm agnostic who does the p= ush. >> >Committed as r215439. >> > >> >>>>>>:> =A0 =A0 http://people.freebsd.org/~tijl/cc-m32-2.diff >> >>>>>>:> =A0 =A0 http://people.freebsd.org/~tijl/cc-m32-3.diff >> >>Now that we have tbemd in the tree, we should take a fresh look at the= se >> >>patches. =A0I'll try to look at these later today as well. >> >I've updated them to today's CURRENT. They're a bit smaller now because >> >some amd64 headers have been moved to x86. This also solved the problem >> >with the kdump build. >> > >> >Here are the commit logs: >> > >> >cc-m32-2.diff: >> > >> > =A0 =A0 Install i386 headers on amd64. >> > >> > =A0 =A0 Machine specific headers for an architecture $arch are now ins= talled >> > =A0 =A0 under /usr/include/$arch. This means machine headers are alway= s in the >> > =A0 =A0 same location whether you are cross compiling or not. >> > >> > =A0 =A0 /usr/include/machine is a symlink to /usr/include/${MACHINE}. >> Yea, I don't like this (the sym link) at all because. =A0Machine headers >> wind up being wrong for amd64, so you have to resort to the following >> kludge. >> >cc-m32-3.diff: >> > =A0 =A0 Modify amd64 headers to include i386 headers when compiling 32= bit >> > =A0 =A0 code. >> > >> > =A0 =A0 All amd64 headers follow the following format: >> > >> > =A0 =A0 #ifndef _AMD64_HEADER_H_ >> > =A0 =A0 #define _AMD64_HEADER_H_ >> > >> > =A0 =A0 #ifdef __i386__ >> > =A0 =A0 #include >> > =A0 =A0 #else >> > >> > =A0 =A0 /* Amd64 declarations go here. */ >> > >> > =A0 =A0 #endif /* __i386__ */ >> > =A0 =A0 #endif /* !_AMD64_HEADER_H_ */ >> ... you wind up with stuff like this, which is also wrong. =A0It preclud= es >> implementing -mpc98 for building on amd64, for example. > Isn't the ABI on pc98 port identical to i386 ABI ? If yes, I do not > see a reason to want -mpc98. > > -m32 is a way to compile for the "32bit usermode twin" of the current > architecture only, and never intended to be a cross-compilation > environment. Hmmm... it seems like the manpage disagrees: -m32 -m64 Generate code for a 32-bit or 64-bit environment. The 32-bit en= vi- ronment sets int, long and pointer to 32 bits and generates code that runs on any i386 system. The 64-bit environment sets int t= o 32 bits and long and pointer to 64 bits and generates code for AMD's x86-64 architecture. For darwin only the -m64 option turns off the -fno-pic and -mdynamic-no-pic options. Then again it doesn't actually state what will happen after the fact in the linking process. >> I'd rather we install {i386,amd64} into /usr/include/ and have machine >> be generated from those two directories (or three, if we supported >> -mpc98 ever). =A0That way, we wouldn't "forget" to add this code to new >> headers, etc. =A0The generated code would be trivial: >> >> #ifdef __i386__ >> #include >> #else >> #include >> #endif >> >> (which is extensible to support pc98 too, if we wanted to add -mpc98). >> >> Of course, I'd really rather we have a /usr/include32 which has a >> separate, pristine copy of everything in it. =A0But that's a much larger >> patch. =A0I think it would be cleaner, but there seems to be universal >> resistance to this sort of scheme. >> >> Warner >> >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >