From owner-freebsd-arch@FreeBSD.ORG Mon Nov 15 23:56:48 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 0EBE21065693 for ; Mon, 15 Nov 2010 23:56:48 +0000 (UTC) (envelope-from dickey@his.com) Received: from smtp105.his.com (smtp105.his.com [216.194.225.42]) by mx1.freebsd.org (Postfix) with ESMTP id CFD0B8FC18 for ; Mon, 15 Nov 2010 23:56:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp105.his.com (Postfix) with ESMTP id 8E5AA29017B for ; Mon, 15 Nov 2010 18:37:39 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at smtp105.his.com X-Spam-Flag: NO X-Spam-Score: 0.758 X-Spam-Level: X-Spam-Status: No, score=0.758 tagged_above=-99 required=5 tests=[AWL=-0.372, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, SPF_PASS=-0.001] Received: from smtp105.his.com ([127.0.0.1]) by localhost (smtp105.his.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgN0PwGmVV1x for ; Mon, 15 Nov 2010 18:37:38 -0500 (EST) Received: from mail101.his.com (dc-7.his.net [108.56.65.7]) by smtp105.his.com (Postfix) with ESMTP id 002F229013D for ; Mon, 15 Nov 2010 18:37:37 -0500 (EST) Received: from mail101.his.com (localhost [127.0.0.1]) by mail101.his.com (8.14.3/8.13.3) with ESMTP id oAFNajch030093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Nov 2010 18:36:45 -0500 (EST) (envelope-from dickey@his.com) Received: from localhost (dickey@localhost) by mail101.his.com (8.14.3/8.13.4/Submit) with ESMTP id oAFNaiEP030090 for ; Mon, 15 Nov 2010 18:36:45 -0500 (EST) (envelope-from dickey@his.com) X-Authentication-Warning: mail101.his.com: dickey owned process doing -bs Date: Mon, 15 Nov 2010 18:36:44 -0500 (EST) From: Thomas Dickey To: freebsd-arch@freebsd.org Message-ID: <20101115183323.I78529@mail101.his.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: re: Moving flex and yacc to contrib/, all hell breaks loose? 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: Mon, 15 Nov 2010 23:56:48 -0000 David O'Brien emitted this: >I also note that all the UC Regents' copyrights have been stripped in >byacc-20100610. and this: >I just did a diff of /usr/src/usr.bin/yacc and byacc-20100610. >The changes aren't that large (when ignoring the deleted copyrights >and the code style changes (going away from, not to KNF). He is at best mistaken. Given the various remarks, "best" is unwarranted. I've updated my webpage to provide some relevant coverage. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net From owner-freebsd-arch@FreeBSD.ORG Tue Nov 16 02:07:28 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 D11DE106566B for ; Tue, 16 Nov 2010 02:07:28 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 95C838FC1A for ; Tue, 16 Nov 2010 02:07:28 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id oAG27ShH084307; Mon, 15 Nov 2010 18:07:28 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id oAG27RTv084306; Mon, 15 Nov 2010 18:07:27 -0800 (PST) (envelope-from sgk) Date: Mon, 15 Nov 2010 18:07:27 -0800 From: Steve Kargl To: Thomas Dickey Message-ID: <20101116020727.GA84292@troutmask.apl.washington.edu> References: <20101115183323.I78529@mail101.his.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101115183323.I78529@mail101.his.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-arch@freebsd.org Subject: Re: Moving flex and yacc to contrib/, all hell breaks loose? 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: Tue, 16 Nov 2010 02:07:28 -0000 On Mon, Nov 15, 2010 at 06:36:44PM -0500, Thomas Dickey wrote: > > > >I just did a diff of /usr/src/usr.bin/yacc and byacc-20100610. > >The changes aren't that large (when ignoring the deleted copyrights > >and the code style changes (going away from, not to KNF). > > He is at best mistaken. Given the various remarks, "best" is unwarranted. > > I've updated my webpage to provide some relevant coverage. > Nice summary. Any reason for not contact Bob Corbett? -- Steve From owner-freebsd-arch@FreeBSD.ORG Tue Nov 16 08:56:13 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 5F005106566C for ; Tue, 16 Nov 2010 08:56:13 +0000 (UTC) (envelope-from dickey@his.com) Received: from smtp105.his.com (smtp105.his.com [216.194.225.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2AB628FC12 for ; Tue, 16 Nov 2010 08:56:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp105.his.com (Postfix) with ESMTP id AAD4329017B; Tue, 16 Nov 2010 03:56:11 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at smtp105.his.com X-Spam-Flag: NO X-Spam-Score: 0.669 X-Spam-Level: X-Spam-Status: No, score=0.669 tagged_above=-99 required=5 tests=[AWL=-0.275, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, SPF_PASS=-0.001] Received: from smtp105.his.com ([127.0.0.1]) by localhost (smtp105.his.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7jQMKAsUuV6; Tue, 16 Nov 2010 03:56:10 -0500 (EST) Received: from mail101.his.com (dc-7.his.net [108.56.65.7]) by smtp105.his.com (Postfix) with ESMTP id 96E63290175; Tue, 16 Nov 2010 03:56:10 -0500 (EST) Received: from mail101.his.com (localhost [127.0.0.1]) by mail101.his.com (8.14.3/8.13.3) with ESMTP id oAG8tHU2075819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Nov 2010 03:55:17 -0500 (EST) (envelope-from dickey@his.com) Received: from localhost (dickey@localhost) by mail101.his.com (8.14.3/8.13.4/Submit) with ESMTP id oAG8tGcW075804; Tue, 16 Nov 2010 03:55:17 -0500 (EST) (envelope-from dickey@his.com) X-Authentication-Warning: mail101.his.com: dickey owned process doing -bs Date: Tue, 16 Nov 2010 03:55:16 -0500 (EST) From: Thomas Dickey To: Steve Kargl In-Reply-To: <20101116020727.GA84292@troutmask.apl.washington.edu> Message-ID: <20101116035435.V75667@mail101.his.com> References: <20101115183323.I78529@mail101.his.com> <20101116020727.GA84292@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org Subject: Re: Moving flex and yacc to contrib/, all hell breaks loose? 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: Tue, 16 Nov 2010 08:56:13 -0000 On Mon, 15 Nov 2010, Steve Kargl wrote: > On Mon, Nov 15, 2010 at 06:36:44PM -0500, Thomas Dickey wrote: >> >> >>> I just did a diff of /usr/src/usr.bin/yacc and byacc-20100610. >>> The changes aren't that large (when ignoring the deleted copyrights >>> and the code style changes (going away from, not to KNF). >> >> He is at best mistaken. Given the various remarks, "best" is unwarranted. >> >> I've updated my webpage to provide some relevant coverage. >> > > Nice summary. Any reason for not contact Bob Corbett? iirc, I did try that, but there was no response. (That would have been when I first started making changes). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net From owner-freebsd-arch@FreeBSD.ORG Tue Nov 16 14:36:51 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 11334106564A; Tue, 16 Nov 2010 14:36:51 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id C258F8FC18; Tue, 16 Nov 2010 14:36:50 +0000 (UTC) Received: by iwn39 with SMTP id 39so896420iwn.13 for ; Tue, 16 Nov 2010 06:36:50 -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:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=SKQtBg3lutdJqo8ghwHWZ+s3+OA87TACIHekUo4GS+U=; b=Ya3GAQb3mT7Fwyf4D//5hofeyj/5TunYIEbZ/EcaomilbTf8Ow4GCed09ZdlZLjXmj AKVqDw1tskmwYQnFKmm2l7eV2CNV9cC1LGO4lSbmoCzIh66vbMgoh3I5u1ZA3aM3NZZY ZT6Qo1oraENEKQ8OkZtVDVaktwospTJcLatdU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=bCafUh+EnbS09phKIwmWge0fv5a13fs7fPlBEHaqn0qFcaB5lVjtyUwmiuPVTpxxft RRVsZRD1SnvtGn4jdS4wmdni+j6acj6K4EGQj7njprrFAjfi6qhSRi3qCsa1wZK4HZbv 2UaL0p/pUpx2MY4r8nwRQjV2dO6X44c1Qm3fg= MIME-Version: 1.0 Received: by 10.231.11.3 with SMTP id r3mr5384267ibr.53.1289918210138; Tue, 16 Nov 2010 06:36:50 -0800 (PST) Sender: baptiste.daroussin@gmail.com Received: by 10.231.180.164 with HTTP; Tue, 16 Nov 2010 06:36:50 -0800 (PST) Date: Tue, 16 Nov 2010 15:36:50 +0100 X-Google-Sender-Auth: SWoPm0mX8ZuNsKQ4RVjq9_bna9A Message-ID: From: Baptiste Daroussin To: freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: [PATCH] sync libedit with netbsd 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: Tue, 16 Nov 2010 14:36:51 -0000 Hi all, Here is a new version of the patch, this time it only upgrades libedit without installing the readline compatibility headers (as I have been suggested for a first step) Their should be no regression with this patch. If it gets committed I'll send the FreeBSD's enhancement to upstream so that we can keep sources in sync. http://people.freebsd.org/~bapt/libedit-netbsd-sync.patch regards, Bapt From owner-freebsd-arch@FreeBSD.ORG Tue Nov 16 17:32: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 50F24106564A for ; Tue, 16 Nov 2010 17:32:50 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0E2728FC0A for ; Tue, 16 Nov 2010 17:32:49 +0000 (UTC) Received: by gwj20 with SMTP id 20so516719gwj.13 for ; Tue, 16 Nov 2010 09:32:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to:date :message-id:subject:from:to:cc:content-type; bh=VB0/BTTOECClBYNykYPTZUFT1Mxu0REqhD6NtvntaTI=; b=p13wt5bSkLtswJwhw49pAq3dsVp3Hh1+bnOxo7SrYGPwUeyspijFJgu0lv2qH2eV9g gz14JAKZbFyXEnw0maTpgxGGaTc+/M4by6I8vSyjeFddr7/VeFsZV5NmHtGbLvw6r5DM uhmtjsW5yOfB2CU/2Plavb42gy4uADggpnEZQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; b=JfKAc3NQucn1l7+En/VcU1HwNMsG45JBc9xFbHSy7FEBmNNfRTycayoNnamcTAV3Ya wHeuCktMyEcL4ip4A94Xj9IY5BLny4WfOSRpvNMInaIEd8hDr0sqLX+abPBu0njBlmr8 DhWRe5zFrQ/V3CVM0X7H2bnYIK/Bb0aUqrcV8= MIME-Version: 1.0 Received: by 10.91.24.17 with SMTP id b17mr9907188agj.192.1289927339638; Tue, 16 Nov 2010 09:08:59 -0800 (PST) Received: by 10.236.41.170 with HTTP; Tue, 16 Nov 2010 09:08:59 -0800 (PST) Date: Tue, 16 Nov 2010 17:08:59 +0000 Message-ID: From: "b. f." To: Baptiste Daroussin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arch@FreeBSD.org Subject: Re: [PATCH] sync libedit with netbsd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 17:32:50 -0000 Baptiste Daroussin wrote: >Here is a new version of the patch, this time it only upgrades libedit >without installing the readline compatibility headers (as I have been >suggested for a first step) > >Their[sic] should be no regression with this patch. > >If it gets committed I'll send the FreeBSD's enhancement to upstream >so that we can keep sources in sync. > >http://people.freebsd.org/~bapt/libedit-netbsd-sync.patch Your patch doesn't include at least one recent bugfix: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/filecomplete.c.diff?r1=1.19&r2=1.20&only_with_tag=MAIN Regards, b. From owner-freebsd-arch@FreeBSD.ORG Tue Nov 16 17:54:47 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 A71A9106566C for ; Tue, 16 Nov 2010 17:54:47 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6BBE88FC0C for ; Tue, 16 Nov 2010 17:54:47 +0000 (UTC) Received: by iwn39 with SMTP id 39so1097073iwn.13 for ; Tue, 16 Nov 2010 09:54:46 -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=Ludyg6W8JRgy/yNRMC+Zjq17AjES+eMLgLg93x6m04k=; b=hynxhPmRsiiUzXQ0bPp4V9aYJUfAhtpGa0vGOdsfYeVENPHQxAVma6/yOL7XKldEX5 8fbxgDSI2R6i+6bL81rPemyBsiPxunq4ux/Bp5OrKCvEMODEoUH2X/oEfU2HrCg+JYX6 eZiD00H8VWiiHHZOXMBsmOboRV2/DqL4AD/Ro= 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=lrLH50pHR4g4A7PqukZBOnmPaQjhQ8f+jFvqMPrxeEgPe7KVININQGISgz8VmCYub7 xHEbLXt6pCUj1K3QSdGNBJujhHoqeFql/AcNF+QqfznP8wVGQo0rSkDjkEC5Y1/yzN0b /mHt7MR/xngORZf1OVHCp9SwCGdDfTFKwG2RM= MIME-Version: 1.0 Received: by 10.231.11.3 with SMTP id r3mr5627333ibr.53.1289930085188; Tue, 16 Nov 2010 09:54:45 -0800 (PST) Sender: baptiste.daroussin@gmail.com Received: by 10.231.180.164 with HTTP; Tue, 16 Nov 2010 09:54:43 -0800 (PST) In-Reply-To: References: Date: Tue, 16 Nov 2010 18:54:43 +0100 X-Google-Sender-Auth: k9rdt7fSRQXHG-kWSirBccyc0mw Message-ID: From: Baptiste Daroussin To: bf1783@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org Subject: Re: [PATCH] sync libedit with netbsd 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: Tue, 16 Nov 2010 17:54:47 -0000 2010/11/16 b. f. : > Baptiste Daroussin wrote: >>Here is a new version of the patch, this time it only upgrades libedit >>without installing the readline compatibility headers (as I have been >>suggested for a first step) >> >>Their[sic] should be no regression with this patch. >> >>If it gets committed I'll send the FreeBSD's enhancement to upstream >>so that we can keep sources in sync. >> >>http://people.freebsd.org/~bapt/libedit-netbsd-sync.patch > > Your patch doesn't include at least one recent bugfix: > > http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/filecomplete.c.diff?r= 1=3D1.19&r2=3D1.20&only_with_tag=3DMAIN > > Regards, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 b. > This was the only missing one and now it is included, still same link: http://people.freebsd.org/~bapt/libedit-netbsd-sync.patch From owner-freebsd-arch@FreeBSD.ORG Wed Nov 17 12:19:58 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 52E16106564A for ; Wed, 17 Nov 2010 12:19:58 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 118478FC08 for ; Wed, 17 Nov 2010 12:19:58 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:35d6:3174:5c3b:5304] (unknown [IPv6:2001:7b8:3a7:0:35d6:3174:5c3b:5304]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 28F615C43; Wed, 17 Nov 2010 13:19:57 +0100 (CET) Message-ID: <4CE3C86D.3060501@FreeBSD.org> Date: Wed, 17 Nov 2010 13:19:57 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.13pre) Gecko/20101113 Lanikai/3.1.7pre MIME-Version: 1.0 To: Tijl Coosemans References: <201007291718.12687.tijl@coosemans.org> <201008301731.19074.tijl@coosemans.org> <20100830.123636.59640143160044949.imp@bsdimp.com> <201008302210.07110.tijl@coosemans.org> In-Reply-To: <201008302210.07110.tijl@coosemans.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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 12:19:58 -0000 On 2010-08-30 22:09, Tijl Coosemans wrote: > On Monday 30 August 2010 20:36:36 M. Warner Losh wrote: >> :> http://people.freebsd.org/~tijl/cc-m32-1.diff >> :> http://people.freebsd.org/~tijl/cc-m32-2.diff >> :> http://people.freebsd.org/~tijl/cc-m32-3.diff >> :> >> :> *cc-m32-1.diff* : Let ld and cc find 32 bit libraries. ... >> I have been trying to get the tbemd patches into the tree and these >> patches conflict with them. Can we hold off until I get them in? >> I've had to rebase things myself a dozen times and each time I've only >> been able to get part of the patches in... >> >> I still have the objections from before, but I'll take a look at the >> new patches to see if they are addressed or not. > > Ok, no problem. Could we please commit that first diff, at least? As it is now, -m32 cannot even produce 'hello world', so it will only be an improvement. It doesn't seem to clash with tbemd changes either. This will also help with binutils 2.17 and certain ports, such as valgrind. Apparently our current ld just warns about arch mismatch, but produces a .so file anyway (!!): ... cc -L/usr/lib32 -m32 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length -fno-strict-aliasing -fpic -O -g -fno-omit-frame-pointer -fno-strict-aliasing -Wno-long-long -O2 -pipe -fno-strict-aliasing -Wno-pointer-sign -fno-stack-protector -nodefaultlibs -shared -Wl,-z,interpose,-z,initfirst -L/usr/lib32 -m32 -o vgpreload_core-x86-freebsd.so vgpreload_core_x86_freebsd_so-vg_preloaded.o /usr/bin/ld: warning: i386:x86-64 architecture of input file `/usr/lib/crti.o' is incompatible with i386 output /usr/bin/ld: warning: i386:x86-64 architecture of input file `/usr/lib/crtbeginS.o' is incompatible with i386 output /usr/bin/ld: warning: i386:x86-64 architecture of input file `/usr/lib/crtendS.o' is incompatible with i386 output /usr/bin/ld: warning: i386:x86-64 architecture of input file `/usr/lib/crtn.o' is incompatible with i386 output But in later versions of ld this was changed to a (more appropriate) fatal error. :) Of course the 2nd and 3rd diffs mess around with headers and such, so they'll need more scrutiny, but the first one should be no problem, IMHO. From owner-freebsd-arch@FreeBSD.ORG Wed Nov 17 17:21:15 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EB4A10658AF; Wed, 17 Nov 2010 17:21:15 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id CD2EF8FC18; Wed, 17 Nov 2010 17:21:14 +0000 (UTC) Received: by eyb7 with SMTP id 7so1334168eyb.13 for ; Wed, 17 Nov 2010 09:21:13 -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=LtrSIAd913E/re5SkDS9VwsdEjIGl9RPI1o5ojmCPiU=; b=HteWG2XBrvkddWHvNMCkyeLMSEaE1n4iQqngnRK3aQk06+uOD8BwSKhNn4sXVd/GiJ of8TFJskMCmYFUXtv/gJL8kYdnPSJK04/6S9myj1T+KXMzty1+8tnQQcAQnXDHTL1uGe qg7zSlCWwIjVViLfEsi1X45MdgKzlVBefBi9c= 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=jfdakuw4USVAkrxyecUKk7NB+5MC7IBJifJRQczDedZMteRj3F5qs3epjd0QU87X+B aAUX5ru7/P21+G1s5Xlx2M2rGdHBbAsWwLEONWJK+TA47OUfULg6qFBfNMpZA6QSpvum 7uzqaa7cryPKaBA0UmnvBoK82UfMg9Yj55VJ8= MIME-Version: 1.0 Received: by 10.216.82.197 with SMTP id o47mr9073384wee.45.1290014473067; Wed, 17 Nov 2010 09:21:13 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Wed, 17 Nov 2010 09:21:12 -0800 (PST) In-Reply-To: <4CE3C86D.3060501@FreeBSD.org> References: <201007291718.12687.tijl@coosemans.org> <201008301731.19074.tijl@coosemans.org> <20100830.123636.59640143160044949.imp@bsdimp.com> <201008302210.07110.tijl@coosemans.org> <4CE3C86D.3060501@FreeBSD.org> Date: Wed, 17 Nov 2010 09:21:12 -0800 X-Google-Sender-Auth: XB81vR5gjc1oDomoXY-TYPdrn_o Message-ID: From: Garrett Cooper To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org, Tijl Coosemans , 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: Wed, 17 Nov 2010 17:21:15 -0000 On Wed, Nov 17, 2010 at 4:19 AM, Dimitry Andric wrote: > On 2010-08-30 22:09, Tijl Coosemans wrote: >> >> On Monday 30 August 2010 20:36:36 M. Warner Losh wrote: >>> >>> :> =A0http://people.freebsd.org/~tijl/cc-m32-1.diff >>> :> =A0http://people.freebsd.org/~tijl/cc-m32-2.diff >>> :> =A0http://people.freebsd.org/~tijl/cc-m32-3.diff >>> :> >>> :> =A0*cc-m32-1.diff* : Let ld and cc find 32 bit libraries. > > ... >>> >>> I have been trying to get the tbemd patches into the tree and these >>> patches conflict with them. =A0Can we hold off until I get them in? >>> I've had to rebase things myself a dozen times and each time I've only >>> been able to get part of the patches in... >>> >>> I still have the objections from before, but I'll take a look at the >>> new patches to see if they are addressed or not. >> >> Ok, no problem. > > Could we please commit that first diff, at least? =A0As it is now, -m32 > cannot even produce 'hello world', so it will only be an improvement. > It doesn't seem to clash with tbemd changes either. > > This will also help with binutils 2.17 and certain ports, such as > valgrind. =A0Apparently our current ld just warns about arch mismatch, bu= t > produces a .so file anyway (!!): > > ... > cc -L/usr/lib32 -m32 -O2 -g -Wall -Wmissing-prototypes -Wshadow > -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations > -Wno-format-zero-length -fno-strict-aliasing -fpic -O -g > -fno-omit-frame-pointer -fno-strict-aliasing -Wno-long-long -O2 -pipe > -fno-strict-aliasing -Wno-pointer-sign -fno-stack-protector -nodefaultlib= s > -shared -Wl,-z,interpose,-z,initfirst -L/usr/lib32 -m32 =A0-o > vgpreload_core-x86-freebsd.so vgpreload_core_x86_freebsd_so-vg_preloaded.= o > /usr/bin/ld: warning: i386:x86-64 architecture of input file > `/usr/lib/crti.o' is incompatible with i386 output > /usr/bin/ld: warning: i386:x86-64 architecture of input file > `/usr/lib/crtbeginS.o' is incompatible with i386 output > /usr/bin/ld: warning: i386:x86-64 architecture of input file > `/usr/lib/crtendS.o' is incompatible with i386 output > /usr/bin/ld: warning: i386:x86-64 architecture of input file > `/usr/lib/crtn.o' is incompatible with i386 output > > But in later versions of ld this was changed to a (more appropriate) > fatal error. :) > > Of course the 2nd and 3rd diffs mess around with headers and such, so > they'll need more scrutiny, but the first one should be no problem, > IMHO. I'm sensing that Warner is getting closer to an official solution because a chunk of the tbemd code hit the tree in this past week and a half. So I would hold off on committing that code. Thanks, -Garrett From owner-freebsd-arch@FreeBSD.ORG Wed Nov 17 18:08:02 2010 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 916571065670; Wed, 17 Nov 2010 18:08:02 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 501ED8FC0C; Wed, 17 Nov 2010 18:08:02 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id oAHHwDib051791; Wed, 17 Nov 2010 10:58:13 -0700 (MST) (envelope-from imp@bsdimp.com) Message-ID: <4CE417B3.3030102@bsdimp.com> Date: Wed, 17 Nov 2010 10:58:11 -0700 From: Warner Losh User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Thunderbird/3.1.6 MIME-Version: 1.0 To: Garrett Cooper References: <201007291718.12687.tijl@coosemans.org> <201008301731.19074.tijl@coosemans.org> <20100830.123636.59640143160044949.imp@bsdimp.com> <201008302210.07110.tijl@coosemans.org> <4CE3C86D.3060501@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Warner Losh , Tijl Coosemans , Dimitry Andric , 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 18:08:02 -0000 On 11/17/2010 10:21, Garrett Cooper wrote: > On Wed, Nov 17, 2010 at 4:19 AM, Dimitry Andric wrote: >> On 2010-08-30 22:09, Tijl Coosemans wrote: >>> On Monday 30 August 2010 20:36:36 M. Warner Losh wrote: >>>> :> http://people.freebsd.org/~tijl/cc-m32-1.diff This patch looks good. I agree we should commit it right away. I can do the honors later today, or dim@ can. I'm agnostic who does the push. >>>> :> http://people.freebsd.org/~tijl/cc-m32-2.diff >>>> :> http://people.freebsd.org/~tijl/cc-m32-3.diff Now that we have tbemd in the tree, we should take a fresh look at these patches. I'll try to look at these later today as well. Warner From owner-freebsd-arch@FreeBSD.ORG Wed Nov 17 18:19:38 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B18F61065673; Wed, 17 Nov 2010 18:19:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 26B9B8FC1B; Wed, 17 Nov 2010 18:19:37 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id oAHIJQ6n022294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Nov 2010 20:19:26 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id oAHIJQ27013435; Wed, 17 Nov 2010 20:19:26 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oAHIJQuU013434; Wed, 17 Nov 2010 20:19:26 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 17 Nov 2010 20:19:26 +0200 From: Kostik Belousov To: Warner Losh Message-ID: <20101117181926.GT2392@deviant.kiev.zoral.com.ua> References: <201007291718.12687.tijl@coosemans.org> <201008301731.19074.tijl@coosemans.org> <20100830.123636.59640143160044949.imp@bsdimp.com> <201008302210.07110.tijl@coosemans.org> <4CE3C86D.3060501@FreeBSD.org> <4CE417B3.3030102@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lLP7YDNvIUbjHU23" Content-Disposition: inline In-Reply-To: <4CE417B3.3030102@bsdimp.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: arch@freebsd.org, Dimitry Andric , Tijl Coosemans , Warner Losh , 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: Wed, 17 Nov 2010 18:19:38 -0000 --lLP7YDNvIUbjHU23 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 17, 2010 at 10:58:11AM -0700, Warner Losh wrote: > On 11/17/2010 10:21, Garrett Cooper wrote: > >On Wed, Nov 17, 2010 at 4:19 AM, Dimitry Andric wrote: > >>On 2010-08-30 22:09, Tijl Coosemans wrote: > >>>On Monday 30 August 2010 20:36:36 M. Warner Losh wrote: > >>>>:> http://people.freebsd.org/~tijl/cc-m32-1.diff > This patch looks good. I agree we should commit it right away. I can=20 > do the honors later today, or dim@ can. I'm agnostic who does the push. Tijl is src committer. > >>>>:> http://people.freebsd.org/~tijl/cc-m32-2.diff > >>>>:> http://people.freebsd.org/~tijl/cc-m32-3.diff > Now that we have tbemd in the tree, we should take a fresh look at these= =20 > patches. I'll try to look at these later today as well. >=20 > Warner >=20 > _______________________________________________ > 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" --lLP7YDNvIUbjHU23 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzkHK4ACgkQC3+MBN1Mb4jqTgCcCclknx0jOUlF4EyGOyEIhLYr NnUAoKeVtuYq2SjyX2veHmJi+1nAZ9g/ =xNt7 -----END PGP SIGNATURE----- --lLP7YDNvIUbjHU23-- From owner-freebsd-arch@FreeBSD.ORG Wed Nov 17 19:58:10 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 9ADED106564A; Wed, 17 Nov 2010 19:58:10 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay002.isp.belgacom.be (mailrelay002.isp.belgacom.be [195.238.6.175]) by mx1.freebsd.org (Postfix) with ESMTP id D71C98FC1E; Wed, 17 Nov 2010 19:58:09 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAGvB40xbsb61/2dsb2JhbACUUI1/csBshUsE Received: from 181.190-177-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.177.190.181]) by relay.skynet.be with ESMTP; 17 Nov 2010 20:58:07 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.4/8.14.4) with ESMTP id oAHJw7ZQ005305; Wed, 17 Nov 2010 20:58:07 +0100 (CET) (envelope-from tijl@coosemans.org) From: Tijl Coosemans To: freebsd-arch@freebsd.org Date: Wed, 17 Nov 2010 20:57:51 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.5.2; i386; ; ) References: <201007291718.12687.tijl@coosemans.org> <4CE417B3.3030102@bsdimp.com> In-Reply-To: <4CE417B3.3030102@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2338844.TBlaxosnTs"; protocol="application/pgp-signature"; micalg=pgp-sha256 Content-Transfer-Encoding: 7bit Message-Id: <201011172058.05683.tijl@coosemans.org> Cc: Dimitry Andric , Warner Losh , 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: Wed, 17 Nov 2010 19:58:10 -0000 --nextPart2338844.TBlaxosnTs Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 wrote: >>> On 2010-08-30 22:09, Tijl Coosemans wrote: >>>> On Monday 30 August 2010 20:36:36 M. Warner Losh wrote: >>>>> :> http://people.freebsd.org/~tijl/cc-m32-1.diff > This patch looks good. I agree we should commit it right away. I can=20 > do the honors later today, or dim@ can. I'm agnostic who does the push. Committed as r215439. >>>>> :> http://people.freebsd.org/~tijl/cc-m32-2.diff >>>>> :> http://people.freebsd.org/~tijl/cc-m32-3.diff > Now that we have tbemd in the tree, we should take a fresh look at these= =20 > patches. I'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: Install i386 headers on amd64. =20 Machine specific headers for an architecture $arch are now installed under /usr/include/$arch. This means machine headers are always in the same location whether you are cross compiling or not. =20 /usr/include/machine is a symlink to /usr/include/${MACHINE}. cc-m32-3.diff: Modify amd64 headers to include i386 headers when compiling 32 bit code. =20 All amd64 headers follow the following format: =20 #ifndef _AMD64_HEADER_H_ #define _AMD64_HEADER_H_ =20 #ifdef __i386__ #include #else =20 /* Amd64 declarations go here. */ =20 #endif /* __i386__ */ #endif /* !_AMD64_HEADER_H_ */ --nextPart2338844.TBlaxosnTs Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iF4EABEIAAYFAkzkM80ACgkQfoCS2CCgtivcDgEAiGeLBDR/C7+lPFHcah5nHdq1 gqfTNqpK6WLuNmMy+GMA/2fpNVP43sn1Kk8Zm5pm1MEnOKU1Gmv8qwemM9x8SLXj =8XJc -----END PGP SIGNATURE----- --nextPart2338844.TBlaxosnTs-- From owner-freebsd-arch@FreeBSD.ORG Wed Nov 17 20:39:20 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 E2E7610656A3; Wed, 17 Nov 2010 20:39:20 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 82F1B8FC12; Wed, 17 Nov 2010 20:39:20 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id oAHKUpNG053403; Wed, 17 Nov 2010 13:30:52 -0700 (MST) (envelope-from imp@bsdimp.com) Message-ID: <4CE43B7A.8030202@bsdimp.com> Date: Wed, 17 Nov 2010 13:30:50 -0700 From: Warner Losh User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Thunderbird/3.1.6 MIME-Version: 1.0 To: Tijl Coosemans References: <201007291718.12687.tijl@coosemans.org> <4CE417B3.3030102@bsdimp.com> <201011172058.05683.tijl@coosemans.org> In-Reply-To: <201011172058.05683.tijl@coosemans.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dimitry Andric , Garrett Cooper , Warner Losh , 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 20:39:21 -0000 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 wrote: >>>> On 2010-08-30 22:09, Tijl Coosemans wrote: >>>>> On Monday 30 August 2010 20:36:36 M. Warner Losh wrote: >>>>>> :> http://people.freebsd.org/~tijl/cc-m32-1.diff >> This patch looks good. I agree we should commit it right away. I can >> do the honors later today, or dim@ can. I'm agnostic who does the push. > Committed as r215439. > >>>>>> :> http://people.freebsd.org/~tijl/cc-m32-2.diff >>>>>> :> http://people.freebsd.org/~tijl/cc-m32-3.diff >> Now that we have tbemd in the tree, we should take a fresh look at these >> patches. I'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: > > Install i386 headers on amd64. > > Machine specific headers for an architecture $arch are now installed > under /usr/include/$arch. This means machine headers are always in the > same location whether you are cross compiling or not. > > /usr/include/machine is a symlink to /usr/include/${MACHINE}. Yea, I don't like this (the sym link) at all because. Machine headers wind up being wrong for amd64, so you have to resort to the following kludge. > 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_ */ ... you wind up with stuff like this, which is also wrong. It precludes implementing -mpc98 for building on amd64, for example. 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). That way, we wouldn't "forget" to add this code to new headers, etc. The 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. But that's a much larger patch. I think it would be cleaner, but there seems to be universal resistance to this sort of scheme. Warner From owner-freebsd-arch@FreeBSD.ORG Wed Nov 17 20:55:33 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 EE2AF1065675; Wed, 17 Nov 2010 20:55:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 839458FC1C; Wed, 17 Nov 2010 20:55:33 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id oAHKtPD7031845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Nov 2010 22:55:25 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id oAHKtOZ4014889; Wed, 17 Nov 2010 22:55:24 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oAHKtO36014888; Wed, 17 Nov 2010 22:55:24 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 17 Nov 2010 22:55:24 +0200 From: Kostik Belousov To: Warner Losh Message-ID: <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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ia1W/kazkNZ7h/Wz" Content-Disposition: inline In-Reply-To: <4CE43B7A.8030202@bsdimp.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Warner Losh , freebsd-arch@freebsd.org, Tijl Coosemans , Dimitry Andric , 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: Wed, 17 Nov 2010 20:55:34 -0000 --Ia1W/kazkNZ7h/Wz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 wro= te: > >>>>On 2010-08-30 22:09, Tijl Coosemans wrote: > >>>>>On Monday 30 August 2010 20:36:36 M. Warner Losh wrote: > >>>>>>:> http://people.freebsd.org/~tijl/cc-m32-1.diff > >>This patch looks good. I agree we should commit it right away. I can > >>do the honors later today, or dim@ can. I'm agnostic who does the push. > >Committed as r215439. > > > >>>>>>:> http://people.freebsd.org/~tijl/cc-m32-2.diff > >>>>>>:> http://people.freebsd.org/~tijl/cc-m32-3.diff > >>Now that we have tbemd in the tree, we should take a fresh look at these > >>patches. I'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: > > > > Install i386 headers on amd64. > > > > Machine specific headers for an architecture $arch are now installed > > under /usr/include/$arch. This means machine headers are always in = the > > same location whether you are cross compiling or not. > > > > /usr/include/machine is a symlink to /usr/include/${MACHINE}. > Yea, I don't like this (the sym link) at all because. Machine headers=20 > wind up being wrong for amd64, so you have to resort to the following=20 > kludge. > >cc-m32-3.diff: > > Modify amd64 headers to include i386 headers when compiling 32 bit= =20 > > 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_ */ > ... you wind up with stuff like this, which is also wrong. It precludes= =20 > 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. >=20 > I'd rather we install {i386,amd64} into /usr/include/ and have machine=20 > be generated from those two directories (or three, if we supported=20 > -mpc98 ever). That way, we wouldn't "forget" to add this code to new=20 > headers, etc. The generated code would be trivial: >=20 > #ifdef __i386__ > #include > #else > #include > #endif >=20 > (which is extensible to support pc98 too, if we wanted to add -mpc98). >=20 > Of course, I'd really rather we have a /usr/include32 which has a=20 > separate, pristine copy of everything in it. But that's a much larger=20 > patch. I think it would be cleaner, but there seems to be universal=20 > resistance to this sort of scheme. >=20 > Warner >=20 > _______________________________________________ > 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" --Ia1W/kazkNZ7h/Wz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzkQTwACgkQC3+MBN1Mb4hhyQCfUV8Xgi2OgIjdichxpoNGfuF+ HW4AoNFnc0M99ggFaKB+pWdT1Zq3KS9j =88hY -----END PGP SIGNATURE----- --Ia1W/kazkNZ7h/Wz-- 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" > From owner-freebsd-arch@FreeBSD.ORG Wed Nov 17 21:28: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 8A254106564A; Wed, 17 Nov 2010 21:28:25 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 384928FC12; Wed, 17 Nov 2010 21:28:25 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id oAHLQf7V054042; Wed, 17 Nov 2010 14:26:41 -0700 (MST) (envelope-from imp@bsdimp.com) Message-ID: <4CE4488F.5080305@bsdimp.com> Date: Wed, 17 Nov 2010 14:26:39 -0700 From: Warner Losh User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Thunderbird/3.1.6 MIME-Version: 1.0 To: Kostik Belousov 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> In-Reply-To: <20101117205524.GX2392@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Warner Losh , Tijl Coosemans , Dimitry Andric , freebsd-arch@FreeBSD.org, 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: Wed, 17 Nov 2010 21:28:25 -0000 On 11/17/2010 13:55, Kostik Belousov wrote: > 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 wrote: >>>>>> On 2010-08-30 22:09, Tijl Coosemans wrote: >>>>>>> On Monday 30 August 2010 20:36:36 M. Warner Losh wrote: >>>>>>>> :> http://people.freebsd.org/~tijl/cc-m32-1.diff >>>> This patch looks good. I agree we should commit it right away. I can >>>> do the honors later today, or dim@ can. I'm agnostic who does the push. >>> Committed as r215439. >>> >>>>>>>> :> http://people.freebsd.org/~tijl/cc-m32-2.diff >>>>>>>> :> http://people.freebsd.org/~tijl/cc-m32-3.diff >>>> Now that we have tbemd in the tree, we should take a fresh look at these >>>> patches. I'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: >>> >>> Install i386 headers on amd64. >>> >>> Machine specific headers for an architecture $arch are now installed >>> under /usr/include/$arch. This means machine headers are always in the >>> same location whether you are cross compiling or not. >>> >>> /usr/include/machine is a symlink to /usr/include/${MACHINE}. >> Yea, I don't like this (the sym link) at all because. Machine headers >> wind up being wrong for amd64, so you have to resort to the following >> kludge. >>> 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_ */ >> ... you wind up with stuff like this, which is also wrong. It precludes >> 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. The syscall interface is identical. However, there's a number of differences in the drivers that are hidden behind machine/foo.h, however. Otherwise, we wouldn't bother with two different sets of headers. > -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. Yea, I didn't want to preclude the possibility of a -mpc98, but I do understand that it would be a bit of a kludge. >> 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). That way, we wouldn't "forget" to add this code to new >> headers, etc. The 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. But that's a much larger >> patch. I 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" From owner-freebsd-arch@FreeBSD.ORG Wed Nov 17 22:18: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 48DCC106566B; Wed, 17 Nov 2010 22:18: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 16AF08FC17; Wed, 17 Nov 2010 22:18: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 B0FD246B52; Wed, 17 Nov 2010 17:18:41 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D7A4B8A009; Wed, 17 Nov 2010 17:18:40 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Date: Wed, 17 Nov 2010 17:18:37 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <201007291718.12687.tijl@coosemans.org> <4CE417B3.3030102@bsdimp.com> <201011172058.05683.tijl@coosemans.org> In-Reply-To: <201011172058.05683.tijl@coosemans.org> MIME-Version: 1.0 Message-Id: <201011171718.37798.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 17 Nov 2010 17:18: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: Warner Losh , Tijl Coosemans , Dimitry Andric , 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: Wed, 17 Nov 2010 22:18:42 -0000 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.) -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Nov 17 23:42:51 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 636CA1065672; Wed, 17 Nov 2010 23:42:51 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 04D618FC15; Wed, 17 Nov 2010 23:42:50 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id oAHNWJnq055509; Wed, 17 Nov 2010 16:32:19 -0700 (MST) (envelope-from imp@bsdimp.com) Message-ID: <4CE46602.9000303@bsdimp.com> Date: Wed, 17 Nov 2010 16:32:18 -0700 From: Warner Losh User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Thunderbird/3.1.6 MIME-Version: 1.0 To: John Baldwin References: <201007291718.12687.tijl@coosemans.org> <4CE417B3.3030102@bsdimp.com> <201011172058.05683.tijl@coosemans.org> <201011171718.37798.jhb@freebsd.org> In-Reply-To: <201011171718.37798.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit 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: Wed, 17 Nov 2010 23:42:51 -0000 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. Warner From owner-freebsd-arch@FreeBSD.ORG Thu Nov 18 00:15:39 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 36DFC10656A3; Thu, 18 Nov 2010 00:15:39 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id D8C938FC0A; Thu, 18 Nov 2010 00:15:38 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id oAI08rMf055934; Wed, 17 Nov 2010 17:08:54 -0700 (MST) (envelope-from imp@bsdimp.com) Message-ID: <4CE46E94.7040405@bsdimp.com> Date: Wed, 17 Nov 2010 17:08:52 -0700 From: Warner Losh User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Thunderbird/3.1.6 MIME-Version: 1.0 To: Nathan Whitehorn References: <201007291718.12687.tijl@coosemans.org> <4CE417B3.3030102@bsdimp.com> <201011172058.05683.tijl@coosemans.org> <201011171718.37798.jhb@freebsd.org> <4CE46602.9000303@bsdimp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 00:15:39 -0000 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 :) > > 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. 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. Warner > -Nathan > > > 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 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 From owner-freebsd-arch@FreeBSD.ORG Thu Nov 18 06:15:15 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 BC9471065670; Thu, 18 Nov 2010 06:15:15 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id 0AA378FC15; Thu, 18 Nov 2010 06:15:13 +0000 (UTC) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id oAI51XsR000608; Thu, 18 Nov 2010 16:01:33 +1100 Received: from c122-106-146-145.carlnfd1.nsw.optusnet.com.au (c122-106-146-145.carlnfd1.nsw.optusnet.com.au [122.106.146.145]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id oAI51Kkg001538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Nov 2010 16:01:22 +1100 Date: Thu, 18 Nov 2010 16:01:20 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Warner Losh In-Reply-To: <4CE46602.9000303@bsdimp.com> Message-ID: <20101118154920.S3472@besplex.bde.org> References: <201007291718.12687.tijl@coosemans.org> <4CE417B3.3030102@bsdimp.com> <201011172058.05683.tijl@coosemans.org> <201011171718.37798.jhb@freebsd.org> <4CE46602.9000303@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 06:15:15 -0000 On Wed, 17 Nov 2010, Warner Losh wrote: > On 11/17/2010 15:18, John Baldwin wrote: >> ... >> 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. Doesn't seem so hard to hack cpp for a subdirectory (but harder than adding -I for the whole include path). > 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. Maybe auto-generate machine32 and hack cpp to use that instead of `machine'? Bruce 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 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 From owner-freebsd-arch@FreeBSD.ORG Thu Nov 18 13:29:17 2010 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75D491065670; Thu, 18 Nov 2010 13:29:17 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from fallbackmx10.syd.optusnet.com.au (fallbackmx10.syd.optusnet.com.au [211.29.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id 64B368FC08; Thu, 18 Nov 2010 13:29:14 +0000 (UTC) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by fallbackmx10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id oAIBDm19012662; Thu, 18 Nov 2010 22:13:48 +1100 Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id oAIBDaN2030633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Nov 2010 22:13:38 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id oAIBDXYu099533; Thu, 18 Nov 2010 22:13:33 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id oAIBDWdr099532; Thu, 18 Nov 2010 22:13:32 +1100 (EST) (envelope-from peter) Date: Thu, 18 Nov 2010 22:13:32 +1100 From: Peter Jeremy To: Tijl Coosemans Message-ID: <20101118111332.GA99446@server.vk2pj.dyndns.org> References: <201007291718.12687.tijl@coosemans.org> <201008301731.19074.tijl@coosemans.org> <20100830.123636.59640143160044949.imp@bsdimp.com> <201008302210.07110.tijl@coosemans.org> <4CE3C86D.3060501@FreeBSD.org> <4CE417B3.3030102@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline In-Reply-To: <4CE417B3.3030102@bsdimp.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: arch@FreeBSD.org, Dimitry Andric , Warner Losh , 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 13:29:17 -0000 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Nov-17 10:58:11 -0700, Warner Losh wrote: >On 11/17/2010 10:21, Garrett Cooper wrote: >> On Wed, Nov 17, 2010 at 4:19 AM, Dimitry Andric wrote: >>> On 2010-08-30 22:09, Tijl Coosemans wrote: >>>> On Monday 30 August 2010 20:36:36 M. Warner Losh wrote: >>>>> :> http://people.freebsd.org/~tijl/cc-m32-1.diff >This patch looks good. I agree we should commit it right away. I can=20 >do the honors later today, or dim@ can. I'm agnostic who does the push. >>>>> :> http://people.freebsd.org/~tijl/cc-m32-2.diff >>>>> :> http://people.freebsd.org/~tijl/cc-m32-3.diff >Now that we have tbemd in the tree, we should take a fresh look at these= =20 >patches. I'll try to look at these later today as well. You might also like to look at amd64/112215 - this work should close that PR, whether or not any of the patches from the PR are used. --=20 Peter Jeremy --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkzlClwACgkQ/opHv/APuIcW4gCglQgFQJVVpcjGJSea1n8HNJbO ZeIAn0JIvHveEy5hPrbJT4xOg0CJjJzX =RgDW -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 18 17:43:29 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 19938106564A; Thu, 18 Nov 2010 17:43:29 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay012.isp.belgacom.be (mailrelay012.isp.belgacom.be [195.238.6.179]) by mx1.freebsd.org (Postfix) with ESMTP id 482248FC12; Thu, 18 Nov 2010 17:43:27 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAM7y5ExbsUip/2dsb2JhbACiUnK/E4VLBA Received: from 169.72-177-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.177.72.169]) by relay.skynet.be with ESMTP; 18 Nov 2010 18:43:25 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.4/8.14.4) with ESMTP id oAIHhPlW004350; Thu, 18 Nov 2010 18:43:25 +0100 (CET) (envelope-from tijl@coosemans.org) From: Tijl Coosemans To: freebsd-arch@freebsd.org Date: Thu, 18 Nov 2010 18:43:15 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.5.2; i386; ; ) References: <201007291718.12687.tijl@coosemans.org> <201011172058.05683.tijl@coosemans.org> <4CE43B7A.8030202@bsdimp.com> In-Reply-To: <4CE43B7A.8030202@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5445173.RJdgcoN9Pt"; protocol="application/pgp-signature"; micalg=pgp-sha256 Content-Transfer-Encoding: 7bit Message-Id: <201011181843.23185.tijl@coosemans.org> Cc: Dimitry Andric , 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 17:43:29 -0000 --nextPart5445173.RJdgcoN9Pt Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Wednesday 17 November 2010 21:30:50 Warner Losh wrote: > On 11/17/2010 12:57, Tijl Coosemans wrote: >>>>>>> :> http://people.freebsd.org/~tijl/cc-m32-2.diff >>>>>>> :> http://people.freebsd.org/~tijl/cc-m32-3.diff >> 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: >> >> Install i386 headers on amd64. >> >> Machine specific headers for an architecture $arch are now installed >> under /usr/include/$arch. This means machine headers are always in = the >> same location whether you are cross compiling or not. >> >> /usr/include/machine is a symlink to /usr/include/${MACHINE}. > > Yea, I don't like this (the sym link) at all because. Machine headers=20 > wind up being wrong for amd64, so you have to resort to the following=20 > kludge. > >> 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_ */ > > ... you wind up with stuff like this, which is also wrong. It precludes= =20 > implementing -mpc98 for building on amd64, for example. Maybe I was wrong to call it cross compilation because in this case the resulting binaries also run on the host system. The patches are meant to support only this particular feature of amd64 to make it possible to build emulators/wine on amd64 for instance. I don't think we should ever support general cross compilation like compiling for pc98 on amd64 or for amd64 on i386. Users have to install a real cross compiler with its own include (and lib) directories for that anyway. In this case however the system compiler already compiles and links 32 bit code. It just uses the wrong types at the moment. To fix that there are basically two approaches: change the compiler or change the headers. Personally I prefer the latter because the former would have to be repeated for every compiler. And so that's what the patches do. They add 32 bit types to the amd64 headers and reuse the i386 headers for that. I admit they currently take the blunt shotgun approach by modifying (almost) all amd64 headers in the same way. This could be refined somewhat header by header. Some headers can be moved to x86 and the existing header replaced by a stub that includes the x86 header such as has been done for apm_bios.h. The patch doesn't modify that one. Some other headers don't conflict and can be merged and moved to x86. Some can be merged with only a few changes. For instance, some i386 headers already define some types as 64 bit in case of PAE. You could add "|| defined(__x86_64__)" to that. If the differences between the headers are small, they can be grouped and put behind #ifdef __i386__ =2E.. #else ... #endif. This seems to be the approach taken by NetBSD. Most headers have been merged and moved to x86. Only some of the amd64 headers have #ifdef __x86_64__ ... #else #include #endif. If I understand their Makefiles correctly /usr/include/machine is also a symlink. On OpenBSD as well. The patches would bring us more in line here. > I'd rather we install {i386,amd64} into /usr/include/ and have machine=20 > be generated from those two directories (or three, if we supported=20 > -mpc98 ever). That way, we wouldn't "forget" to add this code to new=20 > headers, etc. The generated code would be trivial: >=20 > #ifdef __i386__ > #include > #else > #include > #endif I'm not entirely opposed to this, but what would this look like on other architectures? For instance, will i386 headers be available under /usr/include/i386 on a i386 system as well? It's not a requirement, but still a nice side effect of the current patches. Also, this would get in the way of headers that have been moved to x86. They wouldn't need this. I also don't think forgetting to add 32 bit support to new amd64 headers will be a significant problem. There haven't been any new headers in years. In the end it's just another machine specific feature that in my opinion belongs in machine specific headers. The difference with other machine specific features is of course that isn't isolated to one header, but rather spread over all of them. That makes it look impressive, but it isn't actually very complicated. So, I'm open to further comments (of course), but I still think the patches take the right approach. --nextPart5445173.RJdgcoN9Pt Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iF4EABEIAAYFAkzlZboACgkQfoCS2CCgtiufhAD+LgzR1thMgrt0QM9LbiKy1KJw KzBzppsWXSXj70DRyL8A/jDsbcPRitBdhPN4VkDfOhKeUG/QvGrw4z9wrBbGTc07 =iYfX -----END PGP SIGNATURE----- --nextPart5445173.RJdgcoN9Pt-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 18 17:55:36 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 E6FA7106564A; Thu, 18 Nov 2010 17:55:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 379A38FC14; Thu, 18 Nov 2010 17:55:35 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id oAIHtT6i065160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Nov 2010 19:55:29 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id oAIHtTPh023767; Thu, 18 Nov 2010 19:55:29 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oAIHtToS023766; Thu, 18 Nov 2010 19:55:29 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 18 Nov 2010 19:55:29 +0200 From: Kostik Belousov To: Tijl Coosemans Message-ID: <20101118175529.GK2392@deviant.kiev.zoral.com.ua> References: <201007291718.12687.tijl@coosemans.org> <201011172058.05683.tijl@coosemans.org> <4CE43B7A.8030202@bsdimp.com> <201011181843.23185.tijl@coosemans.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4USs1MzHaHCyIKuP" Content-Disposition: inline In-Reply-To: <201011181843.23185.tijl@coosemans.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_05, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Garrett Cooper , 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 17:55:37 -0000 --4USs1MzHaHCyIKuP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 18, 2010 at 06:43:15PM +0100, Tijl Coosemans wrote: > On Wednesday 17 November 2010 21:30:50 Warner Losh wrote: > > On 11/17/2010 12:57, Tijl Coosemans wrote: > >>>>>>> :> http://people.freebsd.org/~tijl/cc-m32-2.diff > >>>>>>> :> http://people.freebsd.org/~tijl/cc-m32-3.diff > >> 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: > >> > >> Install i386 headers on amd64. > >> > >> Machine specific headers for an architecture $arch are now instal= led > >> under /usr/include/$arch. This means machine headers are always i= n the > >> same location whether you are cross compiling or not. > >> > >> /usr/include/machine is a symlink to /usr/include/${MACHINE}. > > > > Yea, I don't like this (the sym link) at all because. Machine headers= =20 > > wind up being wrong for amd64, so you have to resort to the following= =20 > > kludge. > > > >> cc-m32-3.diff: > >> Modify amd64 headers to include i386 headers when compiling 32 bi= t 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_ */ > > > > ... you wind up with stuff like this, which is also wrong. It preclude= s=20 > > implementing -mpc98 for building on amd64, for example. >=20 > Maybe I was wrong to call it cross compilation because in this case the > resulting binaries also run on the host system. The patches are meant > to support only this particular feature of amd64 to make it possible to > build emulators/wine on amd64 for instance. I don't think we should > ever support general cross compilation like compiling for pc98 on > amd64 or for amd64 on i386. Users have to install a real cross compiler > with its own include (and lib) directories for that anyway. In this > case however the system compiler already compiles and links 32 bit > code. It just uses the wrong types at the moment. >=20 > To fix that there are basically two approaches: change the compiler or > change the headers. Personally I prefer the latter because the former > would have to be repeated for every compiler. >=20 > And so that's what the patches do. They add 32 bit types to the amd64 > headers and reuse the i386 headers for that. I admit they currently > take the blunt shotgun approach by modifying (almost) all amd64 headers > in the same way. This could be refined somewhat header by header. >=20 > Some headers can be moved to x86 and the existing header replaced by > a stub that includes the x86 header such as has been done for > apm_bios.h. The patch doesn't modify that one. >=20 > Some other headers don't conflict and can be merged and moved to x86. > Some can be merged with only a few changes. For instance, some i386 > headers already define some types as 64 bit in case of PAE. You could > add "|| defined(__x86_64__)" to that. If the differences between the > headers are small, they can be grouped and put behind #ifdef __i386__ > ... #else ... #endif. >=20 > This seems to be the approach taken by NetBSD. Most headers have been > merged and moved to x86. Only some of the amd64 headers have #ifdef > __x86_64__ ... #else #include #endif. If I understand their > Makefiles correctly /usr/include/machine is also a symlink. On OpenBSD > as well. The patches would bring us more in line here. >=20 > > I'd rather we install {i386,amd64} into /usr/include/ and have machine= =20 > > be generated from those two directories (or three, if we supported=20 > > -mpc98 ever). That way, we wouldn't "forget" to add this code to new= =20 > > headers, etc. The generated code would be trivial: > >=20 > > #ifdef __i386__ > > #include > > #else > > #include > > #endif >=20 > I'm not entirely opposed to this, but what would this look like on > other architectures? For instance, will i386 headers be available under > /usr/include/i386 on a i386 system as well? It's not a requirement, but > still a nice side effect of the current patches. >=20 > Also, this would get in the way of headers that have been moved to x86. > They wouldn't need this. >=20 > I also don't think forgetting to add 32 bit support to new amd64 > headers will be a significant problem. There haven't been any new > headers in years. Additional important note is that only machine/ headers really needed by userland compilation must be cared about. The -m32 feature is only to support compilation of usermode programs, not kernel modules. >=20 > In the end it's just another machine specific feature that in my > opinion belongs in machine specific headers. The difference with other > machine specific features is of course that isn't isolated to one > header, but rather spread over all of them. That makes it look > impressive, but it isn't actually very complicated. >=20 > So, I'm open to further comments (of course), but I still think the > patches take the right approach. --4USs1MzHaHCyIKuP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzlaJAACgkQC3+MBN1Mb4jFywCgs6M0lfh+HTPKTeaduzXOP8/x va4AnRrf8uRAu3quyHynmG44ATeH/Kls =OVfC -----END PGP SIGNATURE----- --4USs1MzHaHCyIKuP-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 18 22:21: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 1000C106564A for ; Thu, 18 Nov 2010 22:21:04 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail15.syd.optusnet.com.au (mail15.syd.optusnet.com.au [211.29.132.196]) by mx1.freebsd.org (Postfix) with ESMTP id 9BEE58FC1D for ; Thu, 18 Nov 2010 22:21:03 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail15.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id oAIML0Ck007079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 19 Nov 2010 09:21:01 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id oAIML0jP048098 for ; Fri, 19 Nov 2010 09:21:00 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id oAIML0T5048097 for freebsd-arch@freebsd.org; Fri, 19 Nov 2010 09:21:00 +1100 (EST) (envelope-from peter) Date: Fri, 19 Nov 2010 09:21:00 +1100 From: Peter Jeremy To: freebsd-arch@freebsd.org Message-ID: <20101118222100.GA47116@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Migrating ISA/PCI drivers 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 22:21:04 -0000 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm (belatedly) looking at porting digi(4) to the MPSAFE TTY system and have some architectural questions. The digi(4) driver appears to support 5 different Digi card variants, at least two of which exist in both ISA and PCI variants. Looking at the Digi website, it appears that both PCI and ISA cards are still available (as well as a PCIe card which is unlikely to work with the current driver). I only have access to PCI/Xem cards and so can't test my changes on any other card types. I presume Digi cards are not that popular because noone else has shown any interest in the driver since the MPSAFE TTY changes were announced about 2.5 years ago. How much effort should I invest in adapting code for other card types? In particular, the ISA cards use windowed memory accesses and IO ports where the PCI cards have a single flat memory aperture. Removing support for ISA cards would simplify the code (and remove the need to make decisions about whether I need to do window switches in new code), as well as potentially allowing finer grained locks. My options would seem to be: 1) Rip out the ISA support - this is the cleanest for me but maximises effort for a future person wanting to support ISA Digi cards. 2) Carry forward the ISA code as best I can and ensure new code includes appropriate window switches etc. This maximises my effort but hopefully makes it easier for someone to get ISA cards working. 3) Ignore the ISA code. This is fairly easy but probably requires similar effort to (1) to get it going on ISA since all the code would need to be reviewed to add necessary ISA-specific locking/ window switching. My preference is 1 since it leaves the least cruft (from my point of view) in the code and doesn't give users the false impression that ISA cards work. I would appreciate some advice on the best way forward. In the absence of any input, I will probably stick with option 3 for now but may move to option 1 if the ISA code starts getting in the way. Keep in mind that digi(4) does not currently compile on FreeBSD-8 or later, so any of the above options are an improvement over the status quo, though all are a regression from FreeBSD-7. Of course, if someone has access to other Digi card types and wants to assist with porting and testing, I would be happy to work with them. --=20 Peter Jeremy --AqsLC8rIMeq19msA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkzlpswACgkQ/opHv/APuIducQCgvFKipOlZLB5vBDxLyzVnmR9I bHoAnR49um1WrxSB2LmBcwHiRUXyd1xB =HTRC -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA--