From owner-freebsd-arch@FreeBSD.ORG Mon Aug 30 15:31:22 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 40BD810656A3 for ; Mon, 30 Aug 2010 15:31:22 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay009.isp.belgacom.be (mailrelay009.isp.belgacom.be [195.238.6.176]) by mx1.freebsd.org (Postfix) with ESMTP id D06748FC12 for ; Mon, 30 Aug 2010 15:31:21 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQFAGdqe0xbsRDL/2dsb2JhbACTKY0bcrwShTcE Received: from 203.16-177-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.177.16.203]) by relay.skynet.be with ESMTP; 30 Aug 2010 17:31:19 +0200 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 o7UFVJiO005342 for ; Mon, 30 Aug 2010 17:31:19 +0200 (CEST) (envelope-from tijl@coosemans.org) From: Tijl Coosemans To: freebsd-arch@freebsd.org Date: Mon, 30 Aug 2010 17:31:09 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-PRERELEASE; KDE/4.4.5; i386; ; ) References: <201007291718.12687.tijl@coosemans.org> In-Reply-To: <201007291718.12687.tijl@coosemans.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2583464.2XPOiPN8T5"; protocol="application/pgp-signature"; micalg=pgp-sha256 Content-Transfer-Encoding: 7bit Message-Id: <201008301731.19074.tijl@coosemans.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: Mon, 30 Aug 2010 15:31:22 -0000 --nextPart2583464.2XPOiPN8T5 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Thursday 29 July 2010 17:18:03 Tijl Coosemans wrote: > I've put the initial version of some patches online to support cross > compilation of 32 bit binaries on amd64. It's modelled after how NetBSD > does this. >=20 > With these patches something like "cc -m32 -o test test.c -pthread -lm" > generates a program that runs on FreeBSD/i386. >=20 > 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 >=20 > *cc-m32-1.diff* : Let ld and cc find 32 bit libraries. >=20 > *cc-m32-2.diff* : Install i386 headers on amd64. >=20 > With this patch headers for a particular $arch are always installed > under /usr/include/$arch and /usr/include/machine becomes a symlink. >=20 > A question I have here is how best to clean up the old machine > directory. The patch currently uses 'rm -rf'. >=20 > Another problem I encountered was that during the build of > usr.bin/kdump all headers are searched for definitions of ioctl > requests and a C source code file is generated that includes all those > headers. This fails when both i386 and amd64 headers are installed > because they can't both be included at the same time. For now the patch > simply blacklists /usr/include/i386, but actually all $arch should be > excluded. The ioctl requests can still be found through the machine > symlink. If someone has a better idea... >=20 > *cc-m32-3.diff* : Modify amd64 headers to include i386 headers when > __i386__ is defined. >=20 > This patch modifies the amd64 headers to follow this format: >=20 > #ifndef _AMD64_HEADER_H > #define _AMD64_HEADER_H >=20 > #ifdef __i386__ > #include > #else >=20 > ... >=20 > #endif /* __i386__ */ > #endif /* !_AMD64_HEADER_H */ >=20 > This way including works for -m32. There are a few > i386 headers which don't exist for amd64: >=20 > apm_segments.h > bootinfo.h > cserial.h > elan_mmcr.h > if_wl_wavelan.h > ioctl_bt848.h > ioctl_meteor.h > npx.h > pcaudioio.h > pcb_ext.h > perfmon.h > privatespace.h > smapi.h > speaker.h > vm86.h > xbox.h >=20 > Theoretically a dummy amd64 header should be created for each of them > that just includes the i386 header. The patch does this for npx.h. The > other headers seem to be really i386 specific or even outdated. If it > were ever necessary to cross-compile code that uses them, it would be > easy to modify that code to directly include . >=20 >=20 > Feel free to test the patches and to comment on any part of them. I'd like to move forward with this now. I've rebased the patches above against today's CURRENT. If there are no further objections I'd like to commit them a few days from now, let's say Saturday. --nextPart2583464.2XPOiPN8T5 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) iF4EABEIAAYFAkx7zsYACgkQfoCS2CCgtiuYTgD+McJINo+QmlJzQc8r3pA5fjNm D1UO8me5ljg9xCTevtQA/jU0rSxdQjVF3VRsxdoCpECjVwZ12ECnr1ltF4y7r/xz =eUE5 -----END PGP SIGNATURE----- --nextPart2583464.2XPOiPN8T5-- From owner-freebsd-arch@FreeBSD.ORG Mon Aug 30 16:05:26 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 39D5C1065694 for ; Mon, 30 Aug 2010 16:05:26 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id E0A1C8FC16 for ; Mon, 30 Aug 2010 16:05:23 +0000 (UTC) Received: by qwg5 with SMTP id 5so112452qwg.13 for ; Mon, 30 Aug 2010 09:05:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wYi4nea8a/LjtaeGmecQjLYf6RnbyZVJdKEtpm+0yG8=; b=Ewf3C8f7nvnaNJXwP4cx1FAQcodVolSEDz7cxJlU5rOSXGGDHkAqgSNc7D/XIeTTFE MtEBgg+LSq+flATnPk6x7kCnGEqmBb4Zaqp+Gcofz6m0pENphbd9YmKiA8MzTIYPycUD 0vTRqjlA5PvIpp5o8Z2bgw2MzCgH0wBm7OIrQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=IO/L4xO/XmTBKUN+B/0r8Ib2ZF2lw+7AkbaUXY+k+KBRl8KBnBvg2PyCrGcQdWcEY7 Kj3awYG5ozT5DbfRpMsU7jzsYmAhIz8cY4Qyya5V0jW/7yo/mZnCQZV5p/SjlvJPLSyu Jjw3+WjsxNEUTMOofQ03fqPDHuJJoOGDLPOHw= MIME-Version: 1.0 Received: by 10.224.79.170 with SMTP id p42mr3061278qak.81.1283182801993; Mon, 30 Aug 2010 08:40:01 -0700 (PDT) Received: by 10.229.26.81 with HTTP; Mon, 30 Aug 2010 08:40:01 -0700 (PDT) In-Reply-To: <201008301731.19074.tijl@coosemans.org> References: <201007291718.12687.tijl@coosemans.org> <201008301731.19074.tijl@coosemans.org> Date: Mon, 30 Aug 2010 19:40:01 +0400 Message-ID: From: pluknet To: Tijl Coosemans Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Mon, 30 Aug 2010 16:05:26 -0000 On 30 August 2010 19:31, Tijl Coosemans wrote: > On Thursday 29 July 2010 17:18:03 Tijl Coosemans wrote: >> I've put the initial version of some patches online to support cross >> compilation of 32 bit binaries on amd64. It's modelled after how NetBSD >> does this. >> >> With these patches something like "cc -m32 -o test test.c -pthread -lm" >> generates a program that runs on FreeBSD/i386. >> >> 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. >> >> *cc-m32-2.diff* : Install i386 headers on amd64. >> >> With this patch headers for a particular $arch are always installed >> under /usr/include/$arch and /usr/include/machine becomes a symlink. >> >> A question I have here is how best to clean up the old machine >> directory. The patch currently uses 'rm -rf'. >> >> Another problem I encountered was that during the build of >> usr.bin/kdump all headers are searched for definitions of ioctl >> requests and a C source code file is generated that includes all those >> headers. This fails when both i386 and amd64 headers are installed >> because they can't both be included at the same time. For now the patch >> simply blacklists /usr/include/i386, but actually all $arch should be >> excluded. The ioctl requests can still be found through the machine >> symlink. If someone has a better idea... >> >> *cc-m32-3.diff* : Modify amd64 headers to include i386 headers when >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 __i386__ is defined. >> >> This patch modifies the amd64 headers to follow this format: >> >> =A0 #ifndef _AMD64_HEADER_H >> =A0 #define _AMD64_HEADER_H >> >> =A0 #ifdef __i386__ >> =A0 #include >> =A0 #else >> >> =A0 ... >> >> =A0 #endif /* __i386__ */ >> =A0 #endif /* !_AMD64_HEADER_H */ >> >> This way including works for -m32. There are a few >> i386 headers which don't exist for amd64: >> >> apm_segments.h >> bootinfo.h >> cserial.h >> elan_mmcr.h >> if_wl_wavelan.h >> ioctl_bt848.h >> ioctl_meteor.h >> npx.h >> pcaudioio.h >> pcb_ext.h >> perfmon.h >> privatespace.h >> smapi.h >> speaker.h >> vm86.h >> xbox.h >> >> Theoretically a dummy amd64 header should be created for each of them >> that just includes the i386 header. The patch does this for npx.h. The >> other headers seem to be really i386 specific or even outdated. If it >> were ever necessary to cross-compile code that uses them, it would be >> easy to modify that code to directly include . >> >> >> Feel free to test the patches and to comment on any part of them. > > I'd like to move forward with this now. I've rebased the patches above > against today's CURRENT. If there are no further objections I'd like to > commit them a few days from now, let's say Saturday. > Hi. The trouble I faced while was playing with my -m32 work was a cross buildworld error on amd64 with TARGET set to i386. Have you checked there is no such an issue? --=20 wbr, pluknet From owner-freebsd-arch@FreeBSD.ORG Mon Aug 30 18:49: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 9A41510656B2 for ; Mon, 30 Aug 2010 18:49:41 +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 468938FC20 for ; Mon, 30 Aug 2010 18:49:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o7UIacmf073235; Mon, 30 Aug 2010 12:37:24 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 30 Aug 2010 12:36:36 -0600 (MDT) Message-Id: <20100830.123636.59640143160044949.imp@bsdimp.com> To: tijl@coosemans.org From: "M. Warner Losh" In-Reply-To: <201008301731.19074.tijl@coosemans.org> References: <201007291718.12687.tijl@coosemans.org> <201008301731.19074.tijl@coosemans.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii 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: Mon, 30 Aug 2010 18:49:41 -0000 In message: <201008301731.19074.tijl@coosemans.org> Tijl Coosemans writes: : On Thursday 29 July 2010 17:18:03 Tijl Coosemans wrote: : > I've put the initial version of some patches online to support cross : > compilation of 32 bit binaries on amd64. It's modelled after how NetBSD : > does this. : > : > With these patches something like "cc -m32 -o test test.c -pthread -lm" : > generates a program that runs on FreeBSD/i386. : > : > 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. : > : > *cc-m32-2.diff* : Install i386 headers on amd64. : > : > With this patch headers for a particular $arch are always installed : > under /usr/include/$arch and /usr/include/machine becomes a symlink. : > : > A question I have here is how best to clean up the old machine : > directory. The patch currently uses 'rm -rf'. : > : > Another problem I encountered was that during the build of : > usr.bin/kdump all headers are searched for definitions of ioctl : > requests and a C source code file is generated that includes all those : > headers. This fails when both i386 and amd64 headers are installed : > because they can't both be included at the same time. For now the patch : > simply blacklists /usr/include/i386, but actually all $arch should be : > excluded. The ioctl requests can still be found through the machine : > symlink. If someone has a better idea... : > : > *cc-m32-3.diff* : Modify amd64 headers to include i386 headers when : > __i386__ is defined. : > : > This patch modifies the amd64 headers to follow this format: : > : > #ifndef _AMD64_HEADER_H : > #define _AMD64_HEADER_H : > : > #ifdef __i386__ : > #include : > #else : > : > ... : > : > #endif /* __i386__ */ : > #endif /* !_AMD64_HEADER_H */ : > : > This way including works for -m32. There are a few : > i386 headers which don't exist for amd64: : > : > apm_segments.h : > bootinfo.h : > cserial.h : > elan_mmcr.h : > if_wl_wavelan.h : > ioctl_bt848.h : > ioctl_meteor.h : > npx.h : > pcaudioio.h : > pcb_ext.h : > perfmon.h : > privatespace.h : > smapi.h : > speaker.h : > vm86.h : > xbox.h : > : > Theoretically a dummy amd64 header should be created for each of them : > that just includes the i386 header. The patch does this for npx.h. The : > other headers seem to be really i386 specific or even outdated. If it : > were ever necessary to cross-compile code that uses them, it would be : > easy to modify that code to directly include . : > : > : > Feel free to test the patches and to comment on any part of them. : : I'd like to move forward with this now. I've rebased the patches above : against today's CURRENT. If there are no further objections I'd like to : commit them a few days from now, let's say Saturday. 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. Warner From owner-freebsd-arch@FreeBSD.ORG Mon Aug 30 20:10: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 C570410656AC for ; Mon, 30 Aug 2010 20:10:10 +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 5D2658FC1C for ; Mon, 30 Aug 2010 20:10:09 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALqse0xbsRDL/2dsb2JhbACgaXK/DYU3BA Received: from 203.16-177-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.177.16.203]) by relay.skynet.be with ESMTP; 30 Aug 2010 22:10:08 +0200 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 o7UKA7U4007452; Mon, 30 Aug 2010 22:10:07 +0200 (CEST) (envelope-from tijl@coosemans.org) From: Tijl Coosemans To: freebsd-arch@freebsd.org Date: Mon, 30 Aug 2010 22:09:51 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-PRERELEASE; KDE/4.4.5; i386; ; ) References: <201007291718.12687.tijl@coosemans.org> <201008301731.19074.tijl@coosemans.org> <20100830.123636.59640143160044949.imp@bsdimp.com> In-Reply-To: <20100830.123636.59640143160044949.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1636257.Aag2RgyL72"; protocol="application/pgp-signature"; micalg=pgp-sha256 Content-Transfer-Encoding: 7bit Message-Id: <201008302210.07110.tijl@coosemans.org> Cc: 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: Mon, 30 Aug 2010 20:10:10 -0000 --nextPart1636257.Aag2RgyL72 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Monday 30 August 2010 20:36:36 M. Warner Losh wrote: > In message: <201008301731.19074.tijl@coosemans.org> > Tijl Coosemans writes: > : On Thursday 29 July 2010 17:18:03 Tijl Coosemans wrote: > : > I've put the initial version of some patches online to support cross > : > compilation of 32 bit binaries on amd64. It's modelled after how NetB= SD > : > does this. > : >=20 > : > With these patches something like "cc -m32 -o test test.c -pthread -l= m" > : > generates a program that runs on FreeBSD/i386. > : >=20 > : > 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 > : >=20 > : > *cc-m32-1.diff* : Let ld and cc find 32 bit libraries. > : >=20 > : > *cc-m32-2.diff* : Install i386 headers on amd64. > : >=20 > : > With this patch headers for a particular $arch are always installed > : > under /usr/include/$arch and /usr/include/machine becomes a symlink. > : >=20 > : > A question I have here is how best to clean up the old machine > : > directory. The patch currently uses 'rm -rf'. > : >=20 > : > Another problem I encountered was that during the build of > : > usr.bin/kdump all headers are searched for definitions of ioctl > : > requests and a C source code file is generated that includes all those > : > headers. This fails when both i386 and amd64 headers are installed > : > because they can't both be included at the same time. For now the pat= ch > : > simply blacklists /usr/include/i386, but actually all $arch should be > : > excluded. The ioctl requests can still be found through the machine > : > symlink. If someone has a better idea... > : >=20 > : > *cc-m32-3.diff* : Modify amd64 headers to include i386 headers when > : > __i386__ is defined. > : >=20 > : > This patch modifies the amd64 headers to follow this format: > : >=20 > : > #ifndef _AMD64_HEADER_H > : > #define _AMD64_HEADER_H > : >=20 > : > #ifdef __i386__ > : > #include > : > #else > : >=20 > : > ... > : >=20 > : > #endif /* __i386__ */ > : > #endif /* !_AMD64_HEADER_H */ > : >=20 > : > This way including works for -m32. There are a few > : > i386 headers which don't exist for amd64: > : >=20 > : > apm_segments.h > : > bootinfo.h > : > cserial.h > : > elan_mmcr.h > : > if_wl_wavelan.h > : > ioctl_bt848.h > : > ioctl_meteor.h > : > npx.h > : > pcaudioio.h > : > pcb_ext.h > : > perfmon.h > : > privatespace.h > : > smapi.h > : > speaker.h > : > vm86.h > : > xbox.h > : >=20 > : > Theoretically a dummy amd64 header should be created for each of them > : > that just includes the i386 header. The patch does this for npx.h. The > : > other headers seem to be really i386 specific or even outdated. If it > : > were ever necessary to cross-compile code that uses them, it would be > : > easy to modify that code to directly include . > : >=20 > : >=20 > : > Feel free to test the patches and to comment on any part of them. > :=20 > : I'd like to move forward with this now. I've rebased the patches above > : against today's CURRENT. If there are no further objections I'd like to > : commit them a few days from now, let's say Saturday. >=20 > 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... >=20 > 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. --nextPart1636257.Aag2RgyL72 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) iF4EABEIAAYFAkx8EB4ACgkQfoCS2CCgtivCWwD/eVQcRyrAsE5Qf5naFC6KY6RR OgzH47yaD3E2Ckxf7PYA/3Y1Gntni1jztMBoOufC3v5G4td9W7MC1YH3a1QOT01w =/wnL -----END PGP SIGNATURE----- --nextPart1636257.Aag2RgyL72-- From owner-freebsd-arch@FreeBSD.ORG Mon Aug 30 20:13: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 0D96C10656AA for ; Mon, 30 Aug 2010 20:13:15 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay005.isp.belgacom.be (mailrelay005.isp.belgacom.be [195.238.6.171]) by mx1.freebsd.org (Postfix) with ESMTP id 9B17B8FC1A for ; Mon, 30 Aug 2010 20:13:14 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKute0xbsRDL/2dsb2JhbACgaXK/HYU3BA Received: from 203.16-177-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.177.16.203]) by relay.skynet.be with ESMTP; 30 Aug 2010 22:13:12 +0200 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 o7UKDC50007481; Mon, 30 Aug 2010 22:13:12 +0200 (CEST) (envelope-from tijl@coosemans.org) From: Tijl Coosemans To: freebsd-arch@freebsd.org Date: Mon, 30 Aug 2010 22:13:11 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-PRERELEASE; KDE/4.4.5; i386; ; ) References: <201007291718.12687.tijl@coosemans.org> <201008301731.19074.tijl@coosemans.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4396126.INT6yiKNkN"; protocol="application/pgp-signature"; micalg=pgp-sha256 Content-Transfer-Encoding: 7bit Message-Id: <201008302213.12233.tijl@coosemans.org> Cc: pluknet 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: Mon, 30 Aug 2010 20:13:15 -0000 --nextPart4396126.INT6yiKNkN Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Monday 30 August 2010 17:40:01 pluknet wrote: > On 30 August 2010 19:31, Tijl Coosemans wrote: >> On Thursday 29 July 2010 17:18:03 Tijl Coosemans wrote: >>> I've put the initial version of some patches online to support cross >>> compilation of 32 bit binaries on amd64. It's modelled after how NetBSD >>> does this. >>> >>> With these patches something like "cc -m32 -o test test.c -pthread -lm" >>> generates a program that runs on FreeBSD/i386. >>> >>> 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. >>> >>> *cc-m32-2.diff* : Install i386 headers on amd64. >>> >>> With this patch headers for a particular $arch are always installed >>> under /usr/include/$arch and /usr/include/machine becomes a symlink. >>> >>> A question I have here is how best to clean up the old machine >>> directory. The patch currently uses 'rm -rf'. >>> >>> Another problem I encountered was that during the build of >>> usr.bin/kdump all headers are searched for definitions of ioctl >>> requests and a C source code file is generated that includes all those >>> headers. This fails when both i386 and amd64 headers are installed >>> because they can't both be included at the same time. For now the patch >>> simply blacklists /usr/include/i386, but actually all $arch should be >>> excluded. The ioctl requests can still be found through the machine >>> symlink. If someone has a better idea... >>> >>> *cc-m32-3.diff* : Modify amd64 headers to include i386 headers when >>> __i386__ is defined. >>> >>> This patch modifies the amd64 headers to follow this format: >>> >>> #ifndef _AMD64_HEADER_H >>> #define _AMD64_HEADER_H >>> >>> #ifdef __i386__ >>> #include >>> #else >>> >>> ... >>> >>> #endif /* __i386__ */ >>> #endif /* !_AMD64_HEADER_H */ >>> >>> This way including works for -m32. There are a few >>> i386 headers which don't exist for amd64: >>> >>> apm_segments.h >>> bootinfo.h >>> cserial.h >>> elan_mmcr.h >>> if_wl_wavelan.h >>> ioctl_bt848.h >>> ioctl_meteor.h >>> npx.h >>> pcaudioio.h >>> pcb_ext.h >>> perfmon.h >>> privatespace.h >>> smapi.h >>> speaker.h >>> vm86.h >>> xbox.h >>> >>> Theoretically a dummy amd64 header should be created for each of them >>> that just includes the i386 header. The patch does this for npx.h. The >>> other headers seem to be really i386 specific or even outdated. If it >>> were ever necessary to cross-compile code that uses them, it would be >>> easy to modify that code to directly include . >>> >>> >>> Feel free to test the patches and to comment on any part of them. >> >> I'd like to move forward with this now. I've rebased the patches above >> against today's CURRENT. If there are no further objections I'd like to >> commit them a few days from now, let's say Saturday. >=20 > The trouble I faced while was playing with my -m32 work > was a cross buildworld error on amd64 with TARGET set to i386. > Have you checked there is no such an issue? I tested this with the previous version and now with the current version and it seems to work. --nextPart4396126.INT6yiKNkN 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) iF4EABEIAAYFAkx8ENgACgkQfoCS2CCgtisumQD7B8OyK6SystlYJnVHaWREC8kR EsdlEu73XyhS/GLajNMBAIcAXvnHGbKugXqHOS+j+q9ubHBHlVKqKS2fu1CqUDq+ =bXRO -----END PGP SIGNATURE----- --nextPart4396126.INT6yiKNkN-- From owner-freebsd-arch@FreeBSD.ORG Fri Sep 3 07:56:16 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 2EC7F1065722; Fri, 3 Sep 2010 07:56:16 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E8E278FC0C; Fri, 3 Sep 2010 07:56:14 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA11706; Fri, 03 Sep 2010 10:43:37 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OrQvw-000732-RF; Fri, 03 Sep 2010 10:43:36 +0300 Message-ID: <4C80A728.6090002@freebsd.org> Date: Fri, 03 Sep 2010 10:43:36 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-arch@freebsd.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: newbus: type (max value) for device order 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: Fri, 03 Sep 2010 07:56:16 -0000 device_add_child_ordered() takes order as a parameter of int type. struct device stores it as u_char. This can be confusing, can't it? In fact, up to r203776 we used to use order value of 100000 in acpi.c (which effectively was 160 according to my calculations). Not sure what I want to suggest, perhaps defining DEVICE_MAX_ORDER or something. Or changing the type in struct device to int. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Fri Sep 3 15:37:37 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 90318106582E; Fri, 3 Sep 2010 15:37:37 +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 609EA8FC13; Fri, 3 Sep 2010 15:37:37 +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 048A246B09; Fri, 3 Sep 2010 11:37:37 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 209C38A03C; Fri, 3 Sep 2010 11:37:36 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Fri, 3 Sep 2010 10:01:58 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4C80A728.6090002@freebsd.org> In-Reply-To: <4C80A728.6090002@freebsd.org> MIME-Version: 1.0 Message-Id: <201009031001.58036.jhb@freebsd.org> Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 03 Sep 2010 11:37:36 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-arch@freebsd.org Subject: Re: newbus: type (max value) for device order 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: Fri, 03 Sep 2010 15:37:37 -0000 On Friday, September 03, 2010 3:43:36 am Andriy Gapon wrote: > > device_add_child_ordered() takes order as a parameter of int type. > struct device stores it as u_char. > > This can be confusing, can't it? > In fact, up to r203776 we used to use order value of 100000 in acpi.c (which > effectively was 160 according to my calculations). > > Not sure what I want to suggest, perhaps defining DEVICE_MAX_ORDER or something. > Or changing the type in struct device to int. Just fix device_t to store an int I think. Also, it should probably be a u_int as negative values don't really make sense. -- John Baldwin -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Sep 3 17:07:38 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 5319310656CD; Fri, 3 Sep 2010 17:07:38 +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 EC3F38FC0C; Fri, 3 Sep 2010 17:07:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o83GxMic032794; Fri, 3 Sep 2010 10:59:22 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 03 Sep 2010 10:59:27 -0600 (MDT) Message-Id: <20100903.105927.70320533242210716.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: <201009031001.58036.jhb@freebsd.org> References: <4C80A728.6090002@freebsd.org> <201009031001.58036.jhb@freebsd.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: avg@freebsd.org, freebsd-arch@freebsd.org Subject: Re: newbus: type (max value) for device order 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: Fri, 03 Sep 2010 17:07:38 -0000 In message: <201009031001.58036.jhb@freebsd.org> John Baldwin writes: : On Friday, September 03, 2010 3:43:36 am Andriy Gapon wrote: : > : > device_add_child_ordered() takes order as a parameter of int type. : > struct device stores it as u_char. : > : > This can be confusing, can't it? : > In fact, up to r203776 we used to use order value of 100000 in acpi.c (which : > effectively was 160 according to my calculations). : > : > Not sure what I want to suggest, perhaps defining DEVICE_MAX_ORDER or something. : > Or changing the type in struct device to int. : : Just fix device_t to store an int I think. Also, it should probably be a : u_int as negative values don't really make sense. One caution: u_short flags; /**< internal device flags */ #define DF_ENABLED 1 /* device should be probed/attached */ #define DF_FIXEDCLASS 2 /* devclass specified at create time */ #define DF_WILDCARD 4 /* unit was originally wildcard */ #define DF_DESCMALLOCED 8 /* description was malloced */ #define DF_QUIET 16 /* don't print verbose attach message */ #define DF_DONENOMATCH 32 /* don't execute DEVICE_NOMATCH again */ #define DF_EXTERNALSOFTC 64 /* softc not allocated by us */ #define DF_REBID 128 /* Can rebid after attach */ #define DF_REMAPPED 256 /* all remapping completed */ u_char order; /**< order from device_add_child_ordered() */ u_char pad; I'd be inclined to change this to: u_int flags; /**< internal device flags */ #define DF_ENABLED 1 /* device should be probed/attached */ #define DF_FIXEDCLASS 2 /* devclass specified at create time */ #define DF_WILDCARD 4 /* unit was originally wildcard */ #define DF_DESCMALLOCED 8 /* description was malloced */ #define DF_QUIET 16 /* don't print verbose attach message */ #define DF_DONENOMATCH 32 /* don't execute DEVICE_NOMATCH again */ #define DF_EXTERNALSOFTC 64 /* softc not allocated by us */ #define DF_REBID 128 /* Can rebid after attach */ #define DF_REMAPPED 256 /* all remapping completed */ u_int order; /**< order from device_add_child_ordered() */ so that the padding and such remains consistent. I think this is even an MFCable change, since device_t's size isn't exposed outside of subr_bus.c... Warner From owner-freebsd-arch@FreeBSD.ORG Fri Sep 3 17:51: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 E88A610656A6; Fri, 3 Sep 2010 17:51:25 +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 B604E8FC14; Fri, 3 Sep 2010 17:51:25 +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 57CB046B2A; Fri, 3 Sep 2010 13:51:25 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7651B8A04E; Fri, 3 Sep 2010 13:51:24 -0400 (EDT) From: John Baldwin To: "M. Warner Losh" Date: Fri, 3 Sep 2010 13:50:36 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4C80A728.6090002@freebsd.org> <201009031001.58036.jhb@freebsd.org> <20100903.105927.70320533242210716.imp@bsdimp.com> In-Reply-To: <20100903.105927.70320533242210716.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009031350.36931.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 03 Sep 2010 13:51:24 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: avg@freebsd.org, freebsd-arch@freebsd.org Subject: Re: newbus: type (max value) for device order 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: Fri, 03 Sep 2010 17:51:26 -0000 On Friday, September 03, 2010 12:59:27 pm M. Warner Losh wrote: > In message: <201009031001.58036.jhb@freebsd.org> > John Baldwin writes: > : On Friday, September 03, 2010 3:43:36 am Andriy Gapon wrote: > : > > : > device_add_child_ordered() takes order as a parameter of int type. > : > struct device stores it as u_char. > : > > : > This can be confusing, can't it? > : > In fact, up to r203776 we used to use order value of 100000 in acpi.c (which > : > effectively was 160 according to my calculations). > : > > : > Not sure what I want to suggest, perhaps defining DEVICE_MAX_ORDER or something. > : > Or changing the type in struct device to int. > : > : Just fix device_t to store an int I think. Also, it should probably be a > : u_int as negative values don't really make sense. > > One caution: > u_short flags; /**< internal device flags */ > #define DF_ENABLED 1 /* device should be probed/attached */ > #define DF_FIXEDCLASS 2 /* devclass specified at create time */ > #define DF_WILDCARD 4 /* unit was originally wildcard */ > #define DF_DESCMALLOCED 8 /* description was malloced */ > #define DF_QUIET 16 /* don't print verbose attach message */ > #define DF_DONENOMATCH 32 /* don't execute DEVICE_NOMATCH again */ > #define DF_EXTERNALSOFTC 64 /* softc not allocated by us */ > #define DF_REBID 128 /* Can rebid after attach */ > #define DF_REMAPPED 256 /* all remapping completed */ > u_char order; /**< order from device_add_child_ordered() */ > u_char pad; > > I'd be inclined to change this to: > > u_int flags; /**< internal device flags */ > #define DF_ENABLED 1 /* device should be probed/attached */ > #define DF_FIXEDCLASS 2 /* devclass specified at create time */ > #define DF_WILDCARD 4 /* unit was originally wildcard */ > #define DF_DESCMALLOCED 8 /* description was malloced */ > #define DF_QUIET 16 /* don't print verbose attach message */ > #define DF_DONENOMATCH 32 /* don't execute DEVICE_NOMATCH again */ > #define DF_EXTERNALSOFTC 64 /* softc not allocated by us */ > #define DF_REBID 128 /* Can rebid after attach */ > #define DF_REMAPPED 256 /* all remapping completed */ > u_int order; /**< order from device_add_child_ordered() */ > > so that the padding and such remains consistent. Agreed. > I think this is even an MFCable change, since device_t's size isn't > exposed outside of subr_bus.c... Yes. -- John Baldwin