From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 15:03:10 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A6492754 for ; Wed, 6 Mar 2013 15:03:10 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by mx1.freebsd.org (Postfix) with ESMTP id 601D4F7D for ; Wed, 6 Mar 2013 15:03:09 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UDFs5-00017R-E4; Wed, 06 Mar 2013 15:03:09 +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 r26F35RN003126; Wed, 6 Mar 2013 08:03:05 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18Derx9KBqM92bk1B8iG1SO Subject: Re: cross-compilation of sh(1) from x86 to arm From: Ian Lepore To: Jilles Tjoelker In-Reply-To: <20130303231931.GD21318@stack.nl> References: <20130303231931.GD21318@stack.nl> Content-Type: text/plain; charset="us-ascii" Date: Wed, 06 Mar 2013 08:03:05 -0700 Message-ID: <1362582185.1291.106.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 06 Mar 2013 15:03:10 -0000 On Mon, 2013-03-04 at 00:19 +0100, Jilles Tjoelker wrote: > There has long been a bug in sh(1) where it assumes (in mksyntax.c) that > the properties of char are the same between build and run environments. > This assumption does not hold if a cross build is done for arm on an x86 > machine. The main effect is that such a miscompiled sh incorrectly > handles characters with bit 7 set. Various tests in > tools/regression/bin/sh start failing, possibly in ways that eat huge > amounts of CPU time and memory. > > Christoph Mallon has submitted a fix for this and I have committed it to > head and stable/9. It has, however, only been tested on x86 using the > -funsigned-char compiler option to create the discrepancy. > > Below is a backport of the fix to stable/8. It needs r247733 or at least > the bin/sh/mksyntax.c of that revision. > > Because I had to fix some conflicts and stable/8's sh differs quite a > bit from head's, I would like to have some testing first before > committing this. I again tested only on amd64 with and without the > -funsigned-char compiler option and tools/regression/bin/sh. If the > cross-compilation need not be supported on stable/8, I am fine with > leaving it unfixed in stable/8. It took me a while to get an arm 8-stable environment running to test this. I'm cross-building arm from an i386 build machine running 8.3. Testing with 8-stable @ r247889 before applying your patch, I get two failures: not ok 12 - ./builtins/cd1.0 # wrong exit status not ok 98 - ./expansion/ifs3.0 # wrong exit status After applying your patch, only test 12 fails (still wrong exit status). The failure of test 12 looks like this in both cases: root@dpcur:/tmp/regression/bin/sh # sh -x builtins/cd1.0 + set -e + P=/tmp + cd /tmp + mktemp -d sh-test.XXXXXX + T=sh-test.TkJqGN + chmod 0 sh-test.TkJqGN + cd -L sh-test.TkJqGN + exit 1 If I launch sh and enter that series of commands interactively, the cd -L command returns a status of 0. Now that I've remembered the incantations for getting 8.x to run on my dreamplug I can test things pretty easily if you've got other changes. I also tested -current cross-built on the same machine (using gcc and oabi), and there are no failures there. -- Ian