From owner-freebsd-arm@FreeBSD.ORG Sun Jan 15 01:33:37 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE1B91065676 for ; Sun, 15 Jan 2012 01:33:37 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id AD70D8FC0A for ; Sun, 15 Jan 2012 01:33:37 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta06.emeryville.ca.mail.comcast.net with comcast id Mc9N1i0041smiN4A6dZdsP; Sun, 15 Jan 2012 01:33:37 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta20.emeryville.ca.mail.comcast.net with comcast id MdZc1i0064NgCEG8gdZcLf; Sun, 15 Jan 2012 01:33:37 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q0F1XY0b002355; Sat, 14 Jan 2012 18:33:34 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: David Schultz In-Reply-To: <20120114211039.GA18310@zim.MIT.EDU> References: <1326144525.2199.32.camel@revolution.hippie.lan> <20120111052634.GA96534@zim.MIT.EDU> <20120111101833.GA88428@ci0.org> <1326291254.2419.55.camel@revolution.hippie.lan> <20120111175516.GA99475@zim.MIT.EDU> <1326509894.48691.100.camel@revolution.hippie.lan> <20120114081214.GA14925@zim.MIT.EDU> <1326563626.1678.34.camel@revolution.hippie.lan> <20120114182933.GA17739@zim.MIT.EDU> <1326568038.1678.43.camel@revolution.hippie.lan> <20120114211039.GA18310@zim.MIT.EDU> Content-Type: text/plain Date: Sat, 14 Jan 2012 18:33:34 -0700 Message-Id: <1326591214.1678.85.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm Subject: Re: fenv.h fixes for softfloat X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 01:33:37 -0000 Here are some intermediate results from the llrint() problem before I call it a night... The totally degenerate case to get FE_INVALID set is (long long)1.0; That is, llrint() calls rint() then casts the result to long long. rint() doesn't even break a sweat converting 1.0 to 1.0 and returns with no exception flags set, then the cast from 1.0 to 1LL raises FE_INVALID. With the original value 1.1 instead of 1.0, rint() itself raises FE_INVALID, in the path that falls out the bottom. I added printfs: printf("rint 7a: except %#x\n", fetestexcept(FE_ALL_EXCEPT)); INSERT_WORDS(x,i0,i1); printf("rint 7b: except %#x\n", fetestexcept(FE_ALL_EXCEPT)); STRICT_ASSIGN(double,w,TWO52[sx]+x); printf("rint 7c: except %#x\n", fetestexcept(FE_ALL_EXCEPT)); result = w-TWO52[sx]; printf("rint 8: except %#x i0=%#x i1=%#x x=%g w=%g result=%g\n", fetestexcept(FE_ALL_EXCEPT), i0, i1, x, w, result); return result; And a run using rint(1.1) gave this output: rint 7a: except 0 rint 7b: except 0 rint 7c: except 0x10 rint 8: except 0x10 i0=0x3ff20000 i1=0x9999999a x=1.125 w=4.5036e+15 result=1 I think this may be overall bad news. It seems to imply that certain normal operations on doubles can raise FE_INVALID as a side effect while generating valid results, and because of those words in the spec about how the rounding routines have to behave as if they're a single operation, I think that means that each rounding routine has to check for invalid inputs explicitly and raise FE_INVALID, and otherwise don't let FE_INVALID from rounding or casting leak out to the caller. Ick. Or, maybe the fact that (long long)1.0 raises FE_INVALID is the real problem, like it's not a normal or expected side effect. Hmmm, for that matter, what does the spec say about things like casting raising exceptions? I think I'll go fix dinner and leave you to ponder that. :) -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Jan 16 02:26:50 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A03E6106564A for ; Mon, 16 Jan 2012 02:26:50 +0000 (UTC) (envelope-from das@freebsd.org) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 5F89B8FC08 for ; Mon, 16 Jan 2012 02:26:50 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.5/8.14.2) with ESMTP id q0G2QlWw037242; Sun, 15 Jan 2012 21:26:47 -0500 (EST) (envelope-from das@freebsd.org) Received: (from das@localhost) by zim.MIT.EDU (8.14.5/8.14.2/Submit) id q0G2Qldx037241; Sun, 15 Jan 2012 21:26:47 -0500 (EST) (envelope-from das@freebsd.org) Date: Sun, 15 Jan 2012 21:26:47 -0500 From: David Schultz To: Ian Lepore Message-ID: <20120116022647.GA36657@zim.MIT.EDU> References: <20120111101833.GA88428@ci0.org> <1326291254.2419.55.camel@revolution.hippie.lan> <20120111175516.GA99475@zim.MIT.EDU> <1326509894.48691.100.camel@revolution.hippie.lan> <20120114081214.GA14925@zim.MIT.EDU> <1326563626.1678.34.camel@revolution.hippie.lan> <20120114182933.GA17739@zim.MIT.EDU> <1326568038.1678.43.camel@revolution.hippie.lan> <20120114211039.GA18310@zim.MIT.EDU> <1326591214.1678.85.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1326591214.1678.85.camel@revolution.hippie.lan> Cc: freebsd-arm Subject: Re: fenv.h fixes for softfloat X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 02:26:50 -0000 On Sat, Jan 14, 2012, Ian Lepore wrote: > With the original value 1.1 instead of 1.0, rint() itself raises > FE_INVALID, in the path that falls out the bottom. I added printfs: > > printf("rint 7a: except %#x\n", fetestexcept(FE_ALL_EXCEPT)); > INSERT_WORDS(x,i0,i1); > printf("rint 7b: except %#x\n", fetestexcept(FE_ALL_EXCEPT)); > STRICT_ASSIGN(double,w,TWO52[sx]+x); > printf("rint 7c: except %#x\n", fetestexcept(FE_ALL_EXCEPT)); > result = w-TWO52[sx]; > printf("rint 8: except %#x i0=%#x i1=%#x x=%g w=%g result=%g\n", fetestexcept(FE_ALL_EXCEPT), i0, i1, x, w, result); > return result; > > And a run using rint(1.1) gave this output: > > rint 7a: except 0 > rint 7b: except 0 > rint 7c: except 0x10 > rint 8: except 0x10 i0=0x3ff20000 i1=0x9999999a x=1.125 w=4.5036e+15 result=1 I believe 0x10 is FE_INEXACT on arm, not FE_INVALID. FE_INEXACT is correct here, because w+TWO52[sx] is inexact. That still doesn't explain the lrint() failures, but it makes them less mysterious. For instance, the implementation of the cast from double to int could raise a bogus inexact exception when the number is an integer to begin with. In practice, I think the emulated casts don't raise the proper exceptions even when they should. It might depend on whether it's linking against libgcc's __fixdfsi() or libc's. Nice catch with the _fpmath.h bug, by the way. I'll commit that fix as well. From owner-freebsd-arm@FreeBSD.ORG Mon Jan 16 11:06:57 2012 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B956106566B for ; Mon, 16 Jan 2012 11:06:57 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 894E78FC13 for ; Mon, 16 Jan 2012 11:06:57 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0GB6vOt057566 for ; Mon, 16 Jan 2012 11:06:57 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q0GB6uOI057564 for freebsd-arm@FreeBSD.org; Mon, 16 Jan 2012 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 16 Jan 2012 11:06:56 GMT Message-Id: <201201161106.q0GB6uOI057564@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arm@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 11:06:57 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/162159 arm [panic] USB errors leading to panic on DockStar 9.0-RC o arm/161110 arm /usr/src/sys/arm/include/signal.h is bad o arm/161044 arm devel/icu does not build on arm o arm/160431 arm [busdma] [patch] Disable interrupts during busdma cach o arm/158950 arm arm/sheevaplug fails fsx when mmap operations are enab o arm/156814 arm OpenRD Ultimate does not boot on DB-88F6XXX or SHEEVAP o arm/156496 arm [patch] Minor bugfixes and enhancements to mmc and mmc o arm/155894 arm [patch] Enable at91 booting from SDHC (high capacity) o arm/155214 arm [patch] MMC/SD IO slow on Atmel ARM with modern large o arm/154227 arm [geli] using GELI leads to panic on ARM o arm/154189 arm lang/perl5.12 doesn't build on arm o arm/153380 arm Panic / translation fault with wlan on ARM o arm/150581 arm [irq] Unknown error generates IRQ address decoding err o arm/149288 arm mail/dovecot causes panic during configure on Sheevapl o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 p arm/134338 arm [patch] Lock GPIO accesses on ixp425 16 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Jan 16 16:15:56 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16F361065670 for ; Mon, 16 Jan 2012 16:15:56 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id E97CB8FC14 for ; Mon, 16 Jan 2012 16:15:55 +0000 (UTC) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta07.emeryville.ca.mail.comcast.net with comcast id NGCe1i0051HpZEsA7GFvDr; Mon, 16 Jan 2012 16:15:55 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta14.emeryville.ca.mail.comcast.net with comcast id NGFu1i00D4NgCEG8aGFu2j; Mon, 16 Jan 2012 16:15:55 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q0GGFrrC003930; Mon, 16 Jan 2012 09:15:53 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: David Schultz In-Reply-To: <20120116022647.GA36657@zim.MIT.EDU> References: <20120111101833.GA88428@ci0.org> <1326291254.2419.55.camel@revolution.hippie.lan> <20120111175516.GA99475@zim.MIT.EDU> <1326509894.48691.100.camel@revolution.hippie.lan> <20120114081214.GA14925@zim.MIT.EDU> <1326563626.1678.34.camel@revolution.hippie.lan> <20120114182933.GA17739@zim.MIT.EDU> <1326568038.1678.43.camel@revolution.hippie.lan> <20120114211039.GA18310@zim.MIT.EDU> <1326591214.1678.85.camel@revolution.hippie.lan> <20120116022647.GA36657@zim.MIT.EDU> Content-Type: text/plain Date: Mon, 16 Jan 2012 09:15:52 -0700 Message-Id: <1326730552.1669.29.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm Subject: Re: fenv.h fixes for softfloat X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 16:15:56 -0000 On Sun, 2012-01-15 at 21:26 -0500, David Schultz wrote: > On Sat, Jan 14, 2012, Ian Lepore wrote: > I believe 0x10 is FE_INEXACT on arm, not FE_INVALID. FE_INEXACT > is correct here, because w+TWO52[sx] is inexact. That still > doesn't explain the lrint() failures, but it makes them less > mysterious. For instance, the implementation of the cast from > double to int could raise a bogus inexact exception when the > number is an integer to begin with. In practice, I think the > emulated casts don't raise the proper exceptions even when they > should. It might depend on whether it's linking against libgcc's > __fixdfsi() or libc's. Doh! I could've sworn at one point I was seeing FE_INVALID set after the cast, but now the only thing I'm really sure of is that in jumping from one theory and way of testing it to another I seem to have thoroughly confused myself (and probably you too, sorry about that). So, on theory that there's probably nothing wrong with rint() but maybe something wrong with casting, I tried a test that does what the guts of llrint() does, but breaking the casting into a separate step and looking at the flags after each operation. I also tried casting to (long) versus (long long) and the results are different. Here's the broken down test code: fenv_t env; volatile long long llr; volatile double dr; volatile double _d = 1.0; feclearexcept(FE_ALL_EXCEPT); feholdexcept(&env); printf("except 1: %#x\n", fetestexcept(FE_ALL_EXCEPT)); dr = rint(_d); printf("except 2: %#x\n", fetestexcept(FE_ALL_EXCEPT)); if (fetestexcept(FE_INVALID)) feclearexcept(FE_INEXACT); printf("except 3: %#x\n", fetestexcept(FE_ALL_EXCEPT)); llr = (long)dr; printf("except 4: %#x\n", fetestexcept(FE_ALL_EXCEPT)); llr = (long long)dr; printf("except 5: %#x\n", fetestexcept(FE_ALL_EXCEPT)); feupdateenv(&env); printf("except 6: %#x _d=%f dr=%f llr=%lld\n", fetestexcept(FE_ALL_EXCEPT), _d, dr, llr); And here's the output from running it: except 1: 0 except 2: 0 except 3: 0 except 4: 0 except 5: 0x10 except 6: 0x10 _d=1.000000 dr=1.000000 llr=1 It's interesting that a cast to 32 bits is fine but a cast directly to 64 bits raises FE_INEXACT for the same value. I did spot-check a few values other than 1.0, and they behaved the same (IE, 1.0 is not special, it happens with anything.0), and of course with non-integer starting values FE_INEXACT is set coming out of rint() as you'd expect. BTW, I never reposted the results of running all the tests after fixing the long double printf glitch, but basically it looked like they were identical to the prior results except that the values were printedly correctly. That is, it appears that everything that was failing still failed, but I'm going to confirm that more rigorously soon (like making sure I don't have any forgotten hacks/tweaks in any lib or test code). -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Jan 16 19:51:16 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE3D6106564A for ; Mon, 16 Jan 2012 19:51:16 +0000 (UTC) (envelope-from das@freebsd.org) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 67F258FC18 for ; Mon, 16 Jan 2012 19:51:16 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.5/8.14.2) with ESMTP id q0GJpDg8087382; Mon, 16 Jan 2012 14:51:13 -0500 (EST) (envelope-from das@freebsd.org) Received: (from das@localhost) by zim.MIT.EDU (8.14.5/8.14.2/Submit) id q0GJpDQ7087381; Mon, 16 Jan 2012 14:51:13 -0500 (EST) (envelope-from das@freebsd.org) Date: Mon, 16 Jan 2012 14:51:13 -0500 From: David Schultz To: Ian Lepore Message-ID: <20120116195113.GA87187@zim.MIT.EDU> References: <20120111175516.GA99475@zim.MIT.EDU> <1326509894.48691.100.camel@revolution.hippie.lan> <20120114081214.GA14925@zim.MIT.EDU> <1326563626.1678.34.camel@revolution.hippie.lan> <20120114182933.GA17739@zim.MIT.EDU> <1326568038.1678.43.camel@revolution.hippie.lan> <20120114211039.GA18310@zim.MIT.EDU> <1326591214.1678.85.camel@revolution.hippie.lan> <20120116022647.GA36657@zim.MIT.EDU> <1326730552.1669.29.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1326730552.1669.29.camel@revolution.hippie.lan> Cc: freebsd-arm Subject: Re: fenv.h fixes for softfloat X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 19:51:16 -0000 On Mon, Jan 16, 2012, Ian Lepore wrote: > So, on theory that there's probably nothing wrong with rint() but maybe > something wrong with casting, I tried a test that does what the guts of > llrint() does, but breaking the casting into a separate step and looking > at the flags after each operation. I also tried casting to (long) > versus (long long) and the results are different. Here's the broken > down test code: > > fenv_t env; > volatile long long llr; > volatile double dr; > volatile double _d = 1.0; > > feclearexcept(FE_ALL_EXCEPT); > feholdexcept(&env); > printf("except 1: %#x\n", fetestexcept(FE_ALL_EXCEPT)); > > dr = rint(_d); > printf("except 2: %#x\n", fetestexcept(FE_ALL_EXCEPT)); > > if (fetestexcept(FE_INVALID)) > feclearexcept(FE_INEXACT); > printf("except 3: %#x\n", fetestexcept(FE_ALL_EXCEPT)); > > llr = (long)dr; > printf("except 4: %#x\n", fetestexcept(FE_ALL_EXCEPT)); > > llr = (long long)dr; > printf("except 5: %#x\n", fetestexcept(FE_ALL_EXCEPT)); > > feupdateenv(&env); > printf("except 6: %#x _d=%f dr=%f llr=%lld\n", fetestexcept(FE_ALL_EXCEPT), _d, dr, llr); > > And here's the output from running it: > > except 1: 0 > except 2: 0 > except 3: 0 > except 4: 0 > except 5: 0x10 > except 6: 0x10 _d=1.000000 dr=1.000000 llr=1 > > It's interesting that a cast to 32 bits is fine but a cast directly to > 64 bits raises FE_INEXACT for the same value. The problem is that double->long conversions use the __fixdfsi function in softfloat, but there's no equivalent double->longlong. Instead, a semi-bogus __fixdfdi function is provided in libc/quad. It'll take a little while to come up with a good fix. From owner-freebsd-arm@FreeBSD.ORG Tue Jan 17 19:10:41 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DB50106566C for ; Tue, 17 Jan 2012 19:10:41 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 1BA538FC1B for ; Tue, 17 Jan 2012 19:10:40 +0000 (UTC) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta04.emeryville.ca.mail.comcast.net with comcast id Ngzx1i0061bwxycA4jAgLM; Tue, 17 Jan 2012 19:10:40 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta18.emeryville.ca.mail.comcast.net with comcast id NjAf1i00u4NgCEG8ejAg8J; Tue, 17 Jan 2012 19:10:40 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q0HJAcpH005065; Tue, 17 Jan 2012 12:10:38 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: David Schultz In-Reply-To: <20120116195113.GA87187@zim.MIT.EDU> References: <20120111175516.GA99475@zim.MIT.EDU> <1326509894.48691.100.camel@revolution.hippie.lan> <20120114081214.GA14925@zim.MIT.EDU> <1326563626.1678.34.camel@revolution.hippie.lan> <20120114182933.GA17739@zim.MIT.EDU> <1326568038.1678.43.camel@revolution.hippie.lan> <20120114211039.GA18310@zim.MIT.EDU> <1326591214.1678.85.camel@revolution.hippie.lan> <20120116022647.GA36657@zim.MIT.EDU> <1326730552.1669.29.camel@revolution.hippie.lan> <20120116195113.GA87187@zim.MIT.EDU> Content-Type: text/plain Date: Tue, 17 Jan 2012 12:10:37 -0700 Message-Id: <1326827437.1669.148.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm Subject: Re: fenv.h fixes for softfloat X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 19:10:41 -0000 On Mon, 2012-01-16 at 14:51 -0500, David Schultz wrote: > On Mon, Jan 16, 2012, Ian Lepore wrote: > The problem is that double->long conversions use the __fixdfsi > function in softfloat, but there's no equivalent double->longlong. > Instead, a semi-bogus __fixdfdi function is provided in libc/quad. > It'll take a little while to come up with a good fix. Okay, so cast to 64 bits is a known problem. To see if any other problems are lurking in this area I redefined assert to be non-fatal in test-lrint and ran it so we could see the results of the later tests. It looks like there are two failures (at lines 104 and 108) that aren't related (at least obviously/directly) to the llrint failures. I'll paste the whole log in case my sense of what's "obvious" is wrong... 1..1 nfassert: fetestexcept(FE_ALL_EXCEPT) == (0) file test-lrint.c line 96 while testing llrint: x=1 result=1 excepts=0x10 nfassert: fetestexcept(FE_ALL_EXCEPT) == (0) file test-lrint.c line 96 while testing llrintf: x=1 result=1 excepts=0x10 nfassert: fetestexcept(FE_ALL_EXCEPT) == (0) file test-lrint.c line 96 while testing llrintl: x=1 result=1 excepts=0x10 nfassert: fetestexcept(FE_ALL_EXCEPT) == (0) file test-lrint.c line 97 while testing llrint: x=3.05418e+08 result=305418240 excepts=0x10 nfassert: fetestexcept(FE_ALL_EXCEPT) == (0) file test-lrint.c line 97 while testing llrintf: x=3.05418e+08 result=305418240 excepts=0x10 nfassert: fetestexcept(FE_ALL_EXCEPT) == (0) file test-lrint.c line 97 while testing llrintl: x=3.05418e+08 result=305418240 excepts=0x10 nfassert: fetestexcept(FE_ALL_EXCEPT) == (0x0001) file test-lrint.c line 104 while testing lrint: x=2.14749e+09 result=0 excepts=0x11 nfassert: fetestexcept(FE_ALL_EXCEPT) == (0x0001) file test-lrint.c line 108 while testing lrint: x=-2.14749e+09 result=0 excepts=0x11 nfassert: (llrint)(_d) == (0) || fetestexcept(FE_INVALID) file test-lrint.c line 136 nfassert: fetestexcept(FE_ALL_EXCEPT) == (0x0001) file test-lrint.c line 136 while testing llrint: x=9.22337e+18 result=0 excepts=0 nfassert: (llrintf)(_d) == (0) || fetestexcept(FE_INVALID) file test-lrint.c line 137 nfassert: fetestexcept(FE_ALL_EXCEPT) == (0x0001) file test-lrint.c line 137 while testing llrintf: x=9.22337e+18 result=0 excepts=0 nfassert: fetestexcept(FE_ALL_EXCEPT) == (0) file test-lrint.c line 138 while testing llrint: x=9.22337e+18 result=9223372036854774784 excepts=0x10 nfassert: (llrint)(_d) == (0) || fetestexcept(FE_INVALID) file test-lrint.c line 140 nfassert: fetestexcept(FE_ALL_EXCEPT) == (0x0001) file test-lrint.c line 140 while testing llrint: x=-9.22337e+18 result=0 excepts=0x10 nfassert: (llrintf)(_d) == (0) || fetestexcept(FE_INVALID) file test-lrint.c line 141 nfassert: fetestexcept(FE_ALL_EXCEPT) == (0x0001) file test-lrint.c line 141 while testing llrintf: x=-9.22337e+18 result=0 excepts=0 ok 1 - lrint Zooming in on the two lrint failures, it looks like the rint() routine raises INEXACT and the cast to long raises INVALID. I came up with that by using instrumented code to print the state of the exception flags at various points within s_rint.c and s_lrint.c The s_lrint.c instrumentation was a problem, and I figured I'd better detail it in case it indicates some wider subtle problem. My goal was to capture and display the flags after rint(), then clean them out so I could separately display the flags raised by the cast, then blend the flags back together so that the flags seen by the caller would be the same as they would have been without my instrumentation changes: dtype fn(type x) { fenv_t env; volatile dtype d; volatile type rx; feholdexcept(&env); rx = roundit(x); printf("after rint %#x\n", fetestexcept(FE_ALL_EXCEPT)); if (fetestexcept(FE_INVALID)) feclearexcept(FE_INEXACT); feupdateenv(&env); feholdexcept(&env); printf("before cast %#x\n", fetestexcept(FE_ALL_EXCEPT)); d = (dtype)rx; printf("after cast %#x\n", fetestexcept(FE_ALL_EXCEPT)); feupdateenv(&env); printf("after update %#x\n", fetestexcept(FE_ALL_EXCEPT)); return (d); } Here are the run results (testing just lines 104 and 108, by moving them into main() making them lines 158 & 160 respectively): tflex# ./test-lrint 1..1 rint 0: except 0 rint 1: except 0 i0=0x41dfffff i1=0xffe00000 sx=0 j0=30 rint 6: except 0 i=0x3fffff j0=0x1e rint 8: except 0x10 i0=0x41dfffff i1=0xffe00000 x=2.14749e+09 w=4.50361e+15 result=2.14749e+09 after rint 0x10 before cast 0 after cast 0x1 after update 0x11 nfassert: fetestexcept(FE_ALL_EXCEPT) == (0x0001) file test-lrint.c line 158 while testing lrint: x=2.14749e+09 result=0 excepts=0x11 rint 0: except 0 rint 1: except 0 i0=0xc1e00000 i1=0x100000 sx=1 j0=31 rint 6: except 0 i=0x1fffff j0=0x1f rint 8: except 0x10 i0=0xc1e00000 i1=0x100000 x=-2.14749e+09 w=-4.50361e+15 result=-2.14749e+09 after rint 0x10 before cast 0 after cast 0x1 after update 0x11 nfassert: fetestexcept(FE_ALL_EXCEPT) == (0x0001) file test-lrint.c line 160 while testing lrint: x=-2.14749e+09 result=0 excepts=0x11 Okay, so all of that is what I summarized above. Here's the problem: To get that output, I had to change __softfloat_float_exception_flags to be declared as volatile in all 3 places it's mentioned (two extern decls and the definition). I tried just casting to volatile in fetestexception() and that alone wasn't enough to printf everything correctly. Before changing that var to volatile, I got this output from the instrumented code: tflex# ./test-lrint 1..1 rint 0: except 0 rint 1: except 0 i0=0x41dfffff i1=0xffe00000 sx=0 j0=30 rint 6: except 0 i=0x3fffff j0=0x1e rint 8: except 0x10 i0=0x41dfffff i1=0xffe00000 x=2.14748e+09 w=4.5036e+15 result=2.14748e+09 after rint 0 before cast 0 after cast 0x1 after update 0x11 nfassert: fetestexcept(FE_ALL_EXCEPT) == (0x0001) file test-lrint.c line 158 while testing lrint: x=2.14748e+09 result=0 excepts=0x11 You can see the insanity there that drove me to try using volatile: rint() says it has raised INEXACT just before returning, but printing the flags immediately upon return from rint() showed 0. But, note that the flag variable was correct because the final feupdateenv() raised it again, so the second feholdenv() must have seen it set, right? But if you can't print the right values along the way, then the compiler is somehow feeling free to re-order the code in such a way that the printfs don't show the right values. If it could do that in such a way as to mess up the printfs, could it do so in a way that had more serious side effects? Notice also that I declared the intermidate vars 'd' and 'rx' as volatile. This was also necessary to prevent re-ordering the code in a way that ruined more than just printfs. It was deferring the cast until the return statement, making all the code trying to print flags and manipulate the fenv between the cast and the return moot. Even though the cast is accomplished with a function call, it's almost as if the optimizer isn't treating it as a normal function call that can have the side effect of modifying a global variable. Note that this last one seems like a real problem, not just "my printfs aren't right". If I add feclearexcept(FE_INVALID) right before the last feupdateenv(), then when the cast raises FE_INVALID it should get cleared and not be seen by the caller of lrint(). But because the cast gets deferred until the return, the caller does see FE_INVALID: tflex# ./test-lrint 1..1 rint 0: except 0 rint 1: except 0 i0=0x41dfffff i1=0xffe00000 sx=0 j0=30 rint 6: except 0 i=0x3fffff j0=0x1e rint 8: except 0x10 i0=0x41dfffff i1=0xffe00000 x=2.14748e+09 w=4.5036e+15 result=2.14748e+09 after rint 0x10 before cast 0 after cast 0 after update 0x10 nfassert: fetestexcept(FE_ALL_EXCEPT) == (0x0001) file test-lrint.c line 158 while testing lrint: x=2.14748e+09 result=0 excepts=0x11 Note that without 'd' being declared volatile the exception flags are 0x11 after the call even though the 0x01 flag was cleared before returning from lrint() (the global flags var was volatile for this run; from the printfs it looks like it was never set, but remember that's because the optimizer relocated the cast to the point of the return). This may all come down to a big steaming pile of compiler buggage that you can't do anything about, but I figured I'd dump out everything I've seen so that if you get future reports of odd behavior you're at least forearmed with some knowledge of the ways wonky things can happen. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Jan 17 20:15:10 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8966106564A for ; Tue, 17 Jan 2012 20:15:09 +0000 (UTC) (envelope-from das@freebsd.org) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id A35828FC13 for ; Tue, 17 Jan 2012 20:15:09 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.5/8.14.2) with ESMTP id q0HKF7PC056320; Tue, 17 Jan 2012 15:15:07 -0500 (EST) (envelope-from das@freebsd.org) Received: (from das@localhost) by zim.MIT.EDU (8.14.5/8.14.2/Submit) id q0HKF7Vx056319; Tue, 17 Jan 2012 15:15:07 -0500 (EST) (envelope-from das@freebsd.org) Date: Tue, 17 Jan 2012 15:15:07 -0500 From: David Schultz To: Ian Lepore Message-ID: <20120117201506.GA56160@zim.MIT.EDU> References: <20120114081214.GA14925@zim.MIT.EDU> <1326563626.1678.34.camel@revolution.hippie.lan> <20120114182933.GA17739@zim.MIT.EDU> <1326568038.1678.43.camel@revolution.hippie.lan> <20120114211039.GA18310@zim.MIT.EDU> <1326591214.1678.85.camel@revolution.hippie.lan> <20120116022647.GA36657@zim.MIT.EDU> <1326730552.1669.29.camel@revolution.hippie.lan> <20120116195113.GA87187@zim.MIT.EDU> <1326827437.1669.148.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1326827437.1669.148.camel@revolution.hippie.lan> Cc: freebsd-arm Subject: Re: fenv.h fixes for softfloat X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 20:15:10 -0000 On Tue, Jan 17, 2012, Ian Lepore wrote: > To get that output, I had to change __softfloat_float_exception_flags to > be declared as volatile in all 3 places it's mentioned (two extern decls > and the definition). I tried just casting to volatile in > fetestexception() and that alone wasn't enough to printf everything > correctly. [...] > You can see the insanity there that drove me to try using volatile: > rint() says it has raised INEXACT just before returning, but printing > the flags immediately upon return from rint() showed 0. But, note that > the flag variable was correct because the final feupdateenv() raised it > again, so the second feholdenv() must have seen it set, right? > > But if you can't print the right values along the way, then the compiler > is somehow feeling free to re-order the code in such a way that the > printfs don't show the right values. If it could do that in such a way > as to mess up the printfs, could it do so in a way that had more serious > side effects? You've hit on an old problem that affects more than just arm. Unfortunately, gcc assumes that floating-point arithmetic has no side effects, and consequently, at higher optimization levels, it often reorders computations incorrectly. C99 specifies an FENV_ACCESS pragma intended to enable or disable such optimizations, but only commercial compilers implement it. You can often force gcc to do the right thing with -frounding-math or lower optimization levels. If declaring the flags variable volatile is enough to get things working, more or less, then perhaps we ought to do that until we have a real 21st-century compiler. Even with the FENV_ACCESS issues fixed, there's another problem. The routines that emulate fp-to-integer conversions (__fixdfdi et al.) are traditionally in the compiler runtime library (libgcc), not libc. If your program links against the symbol from libgcc, that implementation has no way of signaling exceptions, since the rest of the softfloat stuff is in libc. FreeBSD and Linux have most of the symbols in libc as well (for reasons that are mysterious to me), so if you get the libc version, then it might work. See also: http://gcc.gnu.org/wiki/Software_floating_point I can fix some inadequacies in the emulation in FreeBSD's libc, but if programs are getting linked properly, that won't have any effect. I wouldn't worry too much about the exceptions for now, in any case. Programs that actually check them are pretty rare, although that's partly due to the lack of compiler support. If libm functions are producing the right answers, more or less, then things are working well enough for most purposes. From owner-freebsd-arm@FreeBSD.ORG Wed Jan 18 05:54:25 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3D86106566C for ; Wed, 18 Jan 2012 05:54:25 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id A79EC8FC14 for ; Wed, 18 Jan 2012 05:54:25 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q0I5Uqmt068599 for freebsd-arm@freebsd.org; Wed, 18 Jan 2012 05:30:52 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.119] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id ssmfwpg9ihwm4hmb6wpdyiu936; for freebsd-arm@freebsd.org; Wed, 18 Jan 2012 05:30:52 +0000 (UTC) (envelope-from kientzle@freebsd.org) From: Tim Kientzle Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 17 Jan 2012 21:30:51 -0800 Message-Id: <23CB6C35-9450-40BA-9FA3-37C44B328CA8@freebsd.org> To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: ports cross-compilers vs. native toolchain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 05:54:26 -0000 What TGTARCH/TGTABI settings for cross-gcc and cross-binutils match the native arm.arm cross toolchain? Tim From owner-freebsd-arm@FreeBSD.ORG Wed Jan 18 20:23:23 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C3DF1065675 for ; Wed, 18 Jan 2012 20:23:23 +0000 (UTC) (envelope-from dioxinu@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 5624A8FC13 for ; Wed, 18 Jan 2012 20:23:22 +0000 (UTC) Received: by qaea17 with SMTP id a17so1340790qae.13 for ; Wed, 18 Jan 2012 12:23:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ExPP/lulnbcOx7ErYSkXd+GyEtXrObmGkEvg/bU4yf8=; b=NZ7qw9s9xWSUUdo5I1QZhkOpQ/1C2Zc3gXjCgm0La12TPO/r99eZU044xYgykPEE7R 8BcoGXmBlDkV1HUja2/Np7wD0yish+1SM97YCY2UHhw2Di0by2m2C+5HgYvrBhskoNF+ fHlm5zehmdQE2Ug2AXw0tIYTM856M2q9HQCpQ= MIME-Version: 1.0 Received: by 10.224.168.84 with SMTP id t20mr8765673qay.2.1326918202455; Wed, 18 Jan 2012 12:23:22 -0800 (PST) Received: by 10.229.47.140 with HTTP; Wed, 18 Jan 2012 12:23:22 -0800 (PST) In-Reply-To: <23CB6C35-9450-40BA-9FA3-37C44B328CA8@freebsd.org> References: <23CB6C35-9450-40BA-9FA3-37C44B328CA8@freebsd.org> Date: Wed, 18 Jan 2012 22:23:22 +0200 Message-ID: From: "Alex T." To: Tim Kientzle Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-arm@freebsd.org Subject: Re: ports cross-compilers vs. native toolchain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 20:23:23 -0000 If I'm not mistaken, this port is not supposed to be built directly. Well, you may, but from what I see is that there one is supposed to build devel/arm-rtems-gcc, which in its turn defines mentioned variables and builds cross-gcc port. And it looks like the only pair of values is supported is arm/rtems. On 18 January 2012 07:30, Tim Kientzle wrote: > What TGTARCH/TGTABI settings for cross-gcc > and cross-binutils match the native arm.arm cross > toolchain? > > Tim > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@FreeBSD.ORG Wed Jan 18 20:51:17 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0CA6106566C for ; Wed, 18 Jan 2012 20:51:17 +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 5705C8FC08 for ; Wed, 18 Jan 2012 20:51:17 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q0IKbF2g018120 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 18 Jan 2012 13:37:17 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Wed, 18 Jan 2012 13:37:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <23CB6C35-9450-40BA-9FA3-37C44B328CA8@freebsd.org> To: "Alex T." X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Wed, 18 Jan 2012 13:37:17 -0700 (MST) Cc: arm@freebsd.org Subject: Re: ports cross-compilers vs. native toolchain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 20:51:17 -0000 The cross-* ports are more for rtems, and not for FreeBSD also... See 'make xdev' if you want to build native compilers in a = cross-building environment. Warner On Jan 18, 2012, at 1:23 PM, Alex T. wrote: > If I'm not mistaken, this port is not supposed to be built directly. = Well, > you may, but > from what I see is that there one is supposed to build = devel/arm-rtems-gcc, > which in > its turn defines mentioned variables and builds cross-gcc port. > And it looks like the only pair of values is supported is arm/rtems. >=20 > On 18 January 2012 07:30, Tim Kientzle wrote: >=20 >> What TGTARCH/TGTABI settings for cross-gcc >> and cross-binutils match the native arm.arm cross >> toolchain? >>=20 >> Tim >>=20 >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >>=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >=20 >=20 From owner-freebsd-arm@FreeBSD.ORG Thu Jan 19 06:24:56 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40D74106564A for ; Thu, 19 Jan 2012 06:24:56 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id E059D8FC18 for ; Thu, 19 Jan 2012 06:24:55 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q0J5n1jG075558; Thu, 19 Jan 2012 05:49:01 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.119] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id qhmwgsyu9p6avagjvb8atank9i; Thu, 19 Jan 2012 05:49:01 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: Tim Kientzle In-Reply-To: Date: Wed, 18 Jan 2012 21:49:00 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8042D895-3B3D-431E-ADCC-A150BDC838ED@kientzle.com> References: <23CB6C35-9450-40BA-9FA3-37C44B328CA8@freebsd.org> To: Warner Losh X-Mailer: Apple Mail (2.1251.1) Cc: arm@freebsd.org Subject: Re: ports cross-compilers vs. native toolchain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 06:24:56 -0000 I'm trying to build a customized u-boot (so that I can add the bootelf command, which is needed to chain Rafa=C5=82's ubldr version of loader(8)). Of course, I'm trying to build this from TI's sources customized for this board, which means I'm not using the FreeBSD-customized sources from denx.de. Since ubldr is built with the native cross-tools, I've been trying to build u-boot the same way, but I've run into a few problems that make me wonder if it would make more sense to build u-boot with the cross-* ports instead, hence my question. (If I understand correctly, ubldr calls into u-boot, so the two need to be built compatibly, hence the question.) Sounds like I should keep poking at u-boot with the native cross tools=E2=80=A6. Unfortunately, the native cross-version of ld is crashing, and I have not yet been able to successfully build a debug version of the native cross tools so I can figure out why. I'll no doubt have more questions very soon. ;-) Tim On Jan 18, 2012, at 12:37 PM, Warner Losh wrote: > The cross-* ports are more for rtems, and not for FreeBSD also... >=20 > See 'make xdev' if you want to build native compilers in a = cross-building environment. >=20 > Warner >=20 > On Jan 18, 2012, at 1:23 PM, Alex T. wrote: >=20 >> If I'm not mistaken, this port is not supposed to be built directly. = Well, >> you may, but >> from what I see is that there one is supposed to build = devel/arm-rtems-gcc, >> which in >> its turn defines mentioned variables and builds cross-gcc port. >> And it looks like the only pair of values is supported is arm/rtems. >>=20 >> On 18 January 2012 07:30, Tim Kientzle wrote: >>=20 >>> What TGTARCH/TGTABI settings for cross-gcc >>> and cross-binutils match the native arm.arm cross >>> toolchain? >>>=20 >>> Tim From owner-freebsd-arm@FreeBSD.ORG Thu Jan 19 07:55:36 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0BDD106566B for ; Thu, 19 Jan 2012 07:55:36 +0000 (UTC) (envelope-from johny.mattsson@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 407088FC08 for ; Thu, 19 Jan 2012 07:55:35 +0000 (UTC) Received: by wibhq12 with SMTP id hq12so4568214wib.13 for ; Wed, 18 Jan 2012 23:55:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=wlgOoWUXwnX/FM1qIvbN9ISkPwLCiJsRDZeKBdPFIek=; b=ipr/c2/imXbp7gYoGupgMTdryYW0n7MIbhV+y/850KFLk28qX1WTko8gvHM45A6wKy 1hfmLWHN+MEMGC8pW3KmSjwd9+Ph8pic9ZuOsCMYHQ7+hMqFde8hT2OlWLZ993nBN7+n O6MEV+2Iv76fJCJ5K8frG0GAA6Rz/u9ZS/fJY= MIME-Version: 1.0 Received: by 10.180.93.193 with SMTP id cw1mr42121699wib.5.1326958208282; Wed, 18 Jan 2012 23:30:08 -0800 (PST) Sender: johny.mattsson@gmail.com Received: by 10.223.155.207 with HTTP; Wed, 18 Jan 2012 23:30:08 -0800 (PST) In-Reply-To: <8042D895-3B3D-431E-ADCC-A150BDC838ED@kientzle.com> References: <23CB6C35-9450-40BA-9FA3-37C44B328CA8@freebsd.org> <8042D895-3B3D-431E-ADCC-A150BDC838ED@kientzle.com> Date: Thu, 19 Jan 2012 18:30:08 +1100 X-Google-Sender-Auth: NIhVQjTKHuEkrFWJihFlsXl3PEs Message-ID: From: Johny Mattsson To: Tim Kientzle Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: arm@freebsd.org Subject: Re: ports cross-compilers vs. native toolchain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 07:55:36 -0000 On 19 January 2012 16:49, Tim Kientzle wrote: > Sounds like I should keep poking at u-boot with the > native cross tools=E2=80=A6. > When I was building custom uboot binaries for my Sheevaplugs, I used the CodeSourcery pre-built ARM toolchain for Linux (on Linux). It was the path of least resistance for me, and it worked really well. I don't know if that's a workable path for you or not, but I thought I'd throw the suggestion out there. Cheers, /Johny From owner-freebsd-arm@FreeBSD.ORG Thu Jan 19 17:22:01 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03F09106564A for ; Thu, 19 Jan 2012 17:22:01 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id CE3BC8FC15 for ; Thu, 19 Jan 2012 17:22:00 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q0JHLxcY078952; Thu, 19 Jan 2012 17:22:00 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.119] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id npu2g7nmu2v5exj67akxq5vqas; Thu, 19 Jan 2012 17:21:59 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: Date: Thu, 19 Jan 2012 09:21:59 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7E53112E-DE29-4145-B597-D39AA77252C5@kientzle.com> References: <23CB6C35-9450-40BA-9FA3-37C44B328CA8@freebsd.org> <8042D895-3B3D-431E-ADCC-A150BDC838ED@kientzle.com> To: Johny Mattsson X-Mailer: Apple Mail (2.1251.1) Cc: arm@freebsd.org Subject: Re: ports cross-compilers vs. native toolchain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 17:22:01 -0000 On Jan 18, 2012, at 11:30 PM, Johny Mattsson wrote: > On 19 January 2012 16:49, Tim Kientzle wrote: > Sounds like I should keep poking at u-boot with the > native cross tools=85. > =20 > When I was building custom uboot binaries for my Sheevaplugs, I used = the CodeSourcery pre-built ARM toolchain for Linux (on Linux). It was = the path of least resistance for me, and it worked really well. >=20 > I don't know if that's a workable path for you or not, but I thought = I'd throw the suggestion out there. Were this a work project, I would do exactly that in order to keep making forward progress. For the moment, I'm more curious about just how far I can push this using FreeBSD tools only. Tim From owner-freebsd-arm@FreeBSD.ORG Fri Jan 20 15:05:41 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C532106564A for ; Fri, 20 Jan 2012 15:05:41 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id 455618FC0A for ; Fri, 20 Jan 2012 15:05:41 +0000 (UTC) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta09.emeryville.ca.mail.comcast.net with comcast id Pqk11i0031zF43QA9r5h32; Fri, 20 Jan 2012 15:05:41 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta24.emeryville.ca.mail.comcast.net with comcast id Pr5f1i01H4NgCEG8kr5guT; Fri, 20 Jan 2012 15:05:40 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q0KF5c5J008476; Fri, 20 Jan 2012 08:05:38 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: David Schultz In-Reply-To: <20120117201506.GA56160@zim.MIT.EDU> References: <20120114081214.GA14925@zim.MIT.EDU> <1326563626.1678.34.camel@revolution.hippie.lan> <20120114182933.GA17739@zim.MIT.EDU> <1326568038.1678.43.camel@revolution.hippie.lan> <20120114211039.GA18310@zim.MIT.EDU> <1326591214.1678.85.camel@revolution.hippie.lan> <20120116022647.GA36657@zim.MIT.EDU> <1326730552.1669.29.camel@revolution.hippie.lan> <20120116195113.GA87187@zim.MIT.EDU> <1326827437.1669.148.camel@revolution.hippie.lan> <20120117201506.GA56160@zim.MIT.EDU> Content-Type: text/plain Date: Fri, 20 Jan 2012 08:05:38 -0700 Message-Id: <1327071938.13801.9.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm Subject: Re: fenv.h fixes for softfloat X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 15:05:41 -0000 On Tue, 2012-01-17 at 15:15 -0500, David Schultz wrote: > If declaring the flags variable volatile is enough to get things > working, more or less, then perhaps we ought to do that until we > have a real 21st-century compiler. I've been pondering this for a couple days, and I think it's probably a good idea. The problem seems to be that the compiler and optimizer are unaware of the fact that the fenv stuff can change across certain operations, and 'volatile' tells the compiler exactly "this value can change in ways you are unaware of." I can't think of any downside other than trying to figure out/remember 5 years from now why the variable is volatile, and that can be fixed with a little comment nearby. Oh, another thing I've been meaning to mention... Doesn't the mips platform also use software floating point? If so, then I think libc/mips/gen/flt_rounds.c needs to be modified to look more like the one I did for arm, with separate software and hardware implementations. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Jan 20 15:30:07 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19F671065670 for ; Fri, 20 Jan 2012 15:30:07 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) by mx1.freebsd.org (Postfix) with ESMTP id C2EB48FC0A for ; Fri, 20 Jan 2012 15:30:06 +0000 (UTC) Received: from uucp by gromit.grondar.org with local-rmail (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RoGPm-000Eaq-6g for arm@freebsd.org; Fri, 20 Jan 2012 15:30:06 +0000 Received: from localhost ([127.0.0.1] helo=groundzero.grondar.org) by groundzero.grondar.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RoGMT-000DkR-6a; Fri, 20 Jan 2012 15:26:41 +0000 To: Tim Kientzle In-reply-to: <7E53112E-DE29-4145-B597-D39AA77252C5@kientzle.com> References: <23CB6C35-9450-40BA-9FA3-37C44B328CA8@freebsd.org> <8042D895-3B3D-431E-ADCC-A150BDC838ED@kientzle.com> <7E53112E-DE29-4145-B597-D39AA77252C5@kientzle.com> From: Mark Murray Date: Fri, 20 Jan 2012 15:26:41 +0000 Message-Id: Cc: arm@freebsd.org Subject: Re: ports cross-compilers vs. native toolchain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 15:30:07 -0000 Tim Kientzle writes: > > On Jan 18, 2012, at 11:30 PM, Johny Mattsson wrote: > > > On 19 January 2012 16:49, Tim Kientzle wrote: > > Sounds like I should keep poking at u-boot with the native cross > > tools. > > > > When I was building custom uboot binaries for my Sheevaplugs, I used > > the CodeSourcery pre-built ARM toolchain for Linux (on Linux). It was > the path of least resistance for me, and it worked really well. > > > I don't know if that's a workable path for you or not, but I thought > > I'd throw the suggestion out there. > > Were this a work project, I would do exactly that in order to keep > making forward progress. > > For the moment, I'm more curious about just how far I can push this > using FreeBSD tools only. I've locally updated cross-(binutils|gcc|gdb) to the latest stable versions, and they seem to work really well for u-boot, OpenPilot and a couple of other things. I've build-tested them for all the *-*-(binutils|gcc|gdb) instances that I could find, but I've only used arm-eabi-(binutils|gcc|gdb) in anger, and then only for C. M -- Mark R V Murray Cert APS(Open) Dip Phys(Open) BSc Open(Open) BSc(Hons)(Open) Pi: 132511160 From owner-freebsd-arm@FreeBSD.ORG Fri Jan 20 17:55:39 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0859D1065670 for ; Fri, 20 Jan 2012 17:55:39 +0000 (UTC) (envelope-from das@freebsd.org) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id A0E3F8FC1C for ; Fri, 20 Jan 2012 17:55:38 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.5/8.14.2) with ESMTP id q0KHtZ91039692; Fri, 20 Jan 2012 12:55:35 -0500 (EST) (envelope-from das@freebsd.org) Received: (from das@localhost) by zim.MIT.EDU (8.14.5/8.14.2/Submit) id q0KHtZw0039691; Fri, 20 Jan 2012 12:55:35 -0500 (EST) (envelope-from das@freebsd.org) Date: Fri, 20 Jan 2012 12:55:35 -0500 From: David Schultz To: Ian Lepore Message-ID: <20120120175535.GA39600@zim.MIT.EDU> References: <20120114182933.GA17739@zim.MIT.EDU> <1326568038.1678.43.camel@revolution.hippie.lan> <20120114211039.GA18310@zim.MIT.EDU> <1326591214.1678.85.camel@revolution.hippie.lan> <20120116022647.GA36657@zim.MIT.EDU> <1326730552.1669.29.camel@revolution.hippie.lan> <20120116195113.GA87187@zim.MIT.EDU> <1326827437.1669.148.camel@revolution.hippie.lan> <20120117201506.GA56160@zim.MIT.EDU> <1327071938.13801.9.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1327071938.13801.9.camel@revolution.hippie.lan> Cc: freebsd-arm Subject: Re: fenv.h fixes for softfloat X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 17:55:39 -0000 On Fri, Jan 20, 2012, Ian Lepore wrote: > On Tue, 2012-01-17 at 15:15 -0500, David Schultz wrote: > > If declaring the flags variable volatile is enough to get things > > working, more or less, then perhaps we ought to do that until we > > have a real 21st-century compiler. > > I've been pondering this for a couple days, and I think it's probably a > good idea. The problem seems to be that the compiler and optimizer are > unaware of the fact that the fenv stuff can change across certain > operations, and 'volatile' tells the compiler exactly "this value can > change in ways you are unaware of." I can't think of any downside other > than trying to figure out/remember 5 years from now why the variable is > volatile, and that can be fixed with a little comment nearby. To address another issue, I tweaked the implementation in r23036 so that none of the fenv routines are inlined anymore. This should achieve the same result as declaring the variables volatile. The compiler may still assume that it can reorder the floating-point computations around the function calls, however. That's partly what FENV_ACCESS is intended to address. By the way, I checked in a new test in tools/regression/usr.bin/cc, which covers some of the more rudimentary things about the compiler and FP emulation than the libm tests do. It might provide some insight into what needs to be fixed for the libm tests to pass, although I think I know what the answer is, and it's not clear that it's worth the trouble of fixing. > Oh, another thing I've been meaning to mention... Doesn't the mips > platform also use software floating point? If so, then I think > libc/mips/gen/flt_rounds.c needs to be modified to look more like the > one I did for arm, with separate software and hardware implementations. Yes, probably. I haven't looked at it much for lack of time, and because of the difficulties of doing development for platforms I don't have. The MIPS code appears to have been copied from the ARM code verbatim in most cases, so I'm fairly confident that it's all wrong. From owner-freebsd-arm@FreeBSD.ORG Sat Jan 21 07:34:06 2012 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 370B4106566B for ; Sat, 21 Jan 2012 07:34:06 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 10C928FC14 for ; Sat, 21 Jan 2012 07:34:02 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q0L7Y2cK090006; Sat, 21 Jan 2012 07:34:02 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.119] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 6ttvc77xfeta54w2ntfpve74ua; Sat, 21 Jan 2012 07:34:02 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: Date: Fri, 20 Jan 2012 23:34:00 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <23CB6C35-9450-40BA-9FA3-37C44B328CA8@freebsd.org> <8042D895-3B3D-431E-ADCC-A150BDC838ED@kientzle.com> <7E53112E-DE29-4145-B597-D39AA77252C5@kientzle.com> To: arm@FreeBSD.org X-Mailer: Apple Mail (2.1251.1) Cc: Mark Murray Subject: Re: FreeBSD and BeagleBone X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2012 07:34:06 -0000 On Jan 20, 2012, at 7:26 AM, Mark Murray wrote: >> For the moment, I'm more curious about just how far I can push this >> using FreeBSD tools only. > > I've locally updated cross-(binutils|gcc|gdb) to the latest stable > versions, and they seem to work really well for u-boot, OpenPilot and a > couple of other things. Warner's pointer about "make xdev" helped a lot. $ cd /usr/src && make xdev XDEV=arm XDEV_ARCH=arm Then U-boot almost builds with $ cd ~/u-boot $ gmake CROSS_COMPILE=arm-freebsd- am335x_evm_config $ gmake CROSS_COMPILE=arm-freebsd- To actually get it to build, I've had to make two changes to U-Boot sources: * In config.mk, remove "-nostdinc" from CPPFLAGS * In Makefile, add /usr/arm-freebsd/usr/lib/libc.a to PLATFORM_LIBS The first fixes missing stddef.h, stdarg.h headers. (I'm not sure why the -nostdinc works on Linux.) The second is needed to resolve __umodsi3, __udivsi3, etc, functions. (These might be defined in libgcc on Linux, and there's some logic here to try to locate libgcc.) With these, I've been able to rebuild u-boot for the BeagleBone from TI's sources to add the "bootelf" command. (The same changes seem to allow the current source from denx.de to build on FreeBSD.) But ubldr still won't run: U-Boot# fatload mmc 0 0x80008000 ubldr reading ubldr 232591 bytes read U-Boot# bootelf 0x80008000 Anyone else used U-Boot to run ubldr on Arm? Tim From owner-freebsd-arm@FreeBSD.ORG Sat Jan 21 10:30:39 2012 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3EB7106564A; Sat, 21 Jan 2012 10:30:39 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 50D828FC0A; Sat, 21 Jan 2012 10:30:39 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 10E61EF63A; Sat, 21 Jan 2012 11:13:34 +0100 (CET) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id tuNd-vJVmagK; Sat, 21 Jan 2012 11:13:33 +0100 (CET) Received: from [10.0.0.112] (nat3-133.ghnet.pl [91.150.222.133]) by smtp.semihalf.com (Postfix) with ESMTPSA id 116F2EF60F; Sat, 21 Jan 2012 11:13:33 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Rafal Jaworowski In-Reply-To: Date: Sat, 21 Jan 2012 11:13:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <23CB6C35-9450-40BA-9FA3-37C44B328CA8@freebsd.org> <8042D895-3B3D-431E-ADCC-A150BDC838ED@kientzle.com> <7E53112E-DE29-4145-B597-D39AA77252C5@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1084) Cc: arm@FreeBSD.org, Mark Murray Subject: Re: FreeBSD and BeagleBone X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2012 10:30:39 -0000 On 2012-01-21, at 08:34, Tim Kientzle wrote: > On Jan 20, 2012, at 7:26 AM, Mark Murray wrote: >=20 >>> For the moment, I'm more curious about just how far I can push this >>> using FreeBSD tools only. >>=20 >> I've locally updated cross-(binutils|gcc|gdb) to the latest stable >> versions, and they seem to work really well for u-boot, OpenPilot and = a >> couple of other things. >=20 > Warner's pointer about "make xdev" helped a lot. >=20 > $ cd /usr/src && make xdev XDEV=3Darm XDEV_ARCH=3Darm >=20 > Then U-boot almost builds with >=20 > $ cd ~/u-boot > $ gmake CROSS_COMPILE=3Darm-freebsd- am335x_evm_config > $ gmake CROSS_COMPILE=3Darm-freebsd- >=20 > To actually get it to build, I've had to make two changes to U-Boot = sources: > * In config.mk, remove "-nostdinc" from CPPFLAGS > * In Makefile, add /usr/arm-freebsd/usr/lib/libc.a to PLATFORM_LIBS >=20 > The first fixes missing stddef.h, stdarg.h headers. (I'm not > sure why the -nostdinc works on Linux.) >=20 > The second is needed to resolve __umodsi3, __udivsi3, etc, > functions. (These might be defined in libgcc on Linux, and > there's some logic here to try to locate libgcc.) >=20 > With these, I've been able to rebuild u-boot for > the BeagleBone from TI's sources to add the "bootelf" > command. (The same changes seem to allow the current source > from denx.de to build on FreeBSD.) >=20 > But ubldr still won't run: >=20 > U-Boot# fatload mmc 0 0x80008000 ubldr > reading ubldr > 232591 bytes read > U-Boot# bootelf 0x80008000 > >=20 > Anyone else used U-Boot to run ubldr on Arm? Looking at memory addresses you use for loading etc. the problem you = might be hitting is with a linking address range: ubldr by default is = linked against 0x1000000, and the bootelf command would follow this = while parsing ELF and placing code/data in memory. If your system config = does not allow available RAM in this range it would crash / hang. If = this is the case, please try to adjust linking addr range in = sys/boot/arm/uboot/ldscript.arm to fit your layout and see if this = helps. Rafal From owner-freebsd-arm@FreeBSD.ORG Sat Jan 21 23:29:11 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2477A106566B; Sat, 21 Jan 2012 23:29:11 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id D07868FC12; Sat, 21 Jan 2012 23:29:10 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q0LNT9cK093368; Sat, 21 Jan 2012 23:29:09 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.119] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id viirbjvg6jfnbekexwyvbdqxin; Sat, 21 Jan 2012 23:29:09 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: Date: Sat, 21 Jan 2012 15:29:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <101D3416-6B61-4840-A89E-4CF91B0BB8BC@kientzle.com> References: <23CB6C35-9450-40BA-9FA3-37C44B328CA8@freebsd.org> <8042D895-3B3D-431E-ADCC-A150BDC838ED@kientzle.com> <7E53112E-DE29-4145-B597-D39AA77252C5@kientzle.com> To: Rafal Jaworowski X-Mailer: Apple Mail (2.1251.1) Cc: arm@freebsd.org Subject: Re: FreeBSD and BeagleBone X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2012 23:29:11 -0000 On Jan 21, 2012, at 2:13 AM, Rafal Jaworowski wrote: >=20 > On 2012-01-21, at 08:34, Tim Kientzle wrote: >=20 >> On Jan 20, 2012, at 7:26 AM, Mark Murray wrote: >>=20 >>>> For the moment, I'm more curious about just how far I can push this >>>> using FreeBSD tools only. >>>=20 >>=20 >> But ubldr still won't run: >>=20 >> U-Boot# fatload mmc 0 0x80008000 ubldr >> U-Boot# bootelf 0x80008000 >> >>=20 >> Anyone else used U-Boot to run ubldr on Arm? >=20 > Looking at memory addresses you use for loading etc. the problem you = might be hitting is with a linking address range: ubldr by default is = linked against 0x1000000, and the bootelf command would follow this = while parsing ELF and placing code/data in memory. If your system config = does not allow available RAM in this range it would crash / hang. If = this is the case, please try to adjust linking addr range in = sys/boot/arm/uboot/ldscript.arm to fit your layout and see if this = helps. That certainly does help. Setting the ELF linking address to 0x80001000 gets this far: U-Boot# fatload mmc 0 0x82000000 ubldr U-Boot# bootelf 0x82000000 ## Starting application at 0x80001054 Consoles: U-Boot console Compatible API signature found @8ff760c0 I think I need to track down some more information on the memory layout U-Boot uses on this board. I haven't checked yet, but I presume the last lines above are actually being printed by ubldr through the U-Boot console routine. If so, that means I've gotten far enough to use printf debugging to trace through ubldr and start understanding how it works and where it's stopping. Thanks much! Tim P.S. Is it worth trying to generalize the ubldr Makefile to accept some form of link address specification?