cross-compilation of sh(1) from x86 to arm

[Jilles Tjoelker]

On Wed, Mar 06, 2013 at 08:03:05AM -0700, Ian Lepore wrote:
> 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).

Thanks for testing. I will commit the MFC.

> The failure of test 12 looks like this in both cases:

> root at 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.

That part of the test does not work as root. The cd command is supposed
to fail and not change internal state. In 9.x that part of the test is
skipped when running as root; I have just MFC'ed that change.

I never noticed this issue because I always run the tests as a normal
user.

> 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.

Thanks, but I'm not planning to MFC anything more to stable/8/bin/sh
right now. (Unless you'd like to have some (compatible) change from 9.x
or 10.x.)

> I also tested -current cross-built on the same machine (using gcc and
> oabi), and there are no failures there.

Cool.

-- 
Jilles Tjoelker