On Mon, 3 Jun 2019, Ian Lance Taylor wrote:
> > I have results as at r270765, taken with QEMU run in the user emulation
> > mode (I have patches outstanding for configury/Makefiles to correctly
> > support libgo and other library testing with a build sysroot in such a
> > setup, pending the completion of my WDC copyright assignment paperwork
> > with FSF):
> >
> > FAIL: go.test/test/args.go execution, -O2 -g
>
> That is a fairly trivial test so if that one fails then something is
> pretty fundamentally wrong somewhere.
>
> You can run just that test by running
>
> make RUNTESTFLAGS=go-test.exp=args.go check-gcc-go
>
> If it fails you should have an executable gcc/testsuite/go/args.x.
The .log file reports (leading paths edited throughout):
spawn qemu-riscv64 -E
LD_LIBRARY_PATH=.:.../riscv64-linux-gnu/lib64/lp64d/libgo/.libs:.../gcc:.../gcc/lib64/lp64:.../gcc/lib64/lp64d
.../gcc/testsuite/go/args.x
panic: argc
goroutine 1 [running]:
main.main
.../gcc/testsuite/go.test/test/args.go:18
FAIL: go.test/test/args.go execution, -O2 -g
The same happens when this is invoked manually.
> Run that executable as `args.x arg1 arg2`.
That works however. I've modified `sim_spawn', which is declared as:
proc sim_spawn { dest cmdline args }
by adding this line:
clone_output "sim_spawn $dest $cmdline $args"
and it reports no command-line arguments being passed to the test case
from the test harness:
sim_spawn qemu-user-lp64d .../gcc/testsuite/go/args.x
so I gather there is something wrong at an upper level. I'll see if I can
investigate it at one point, but given that it is probably the only test
case that expects arguments I consider it a very low priority issue.
Also not all simulators may support arguments in the first place,
especially for bare metal.
NB I had to make a local copy of `sim_spawn' in the qemu-user-lp64d.exp
board description file used, to get `-E ...' passed to QEMU with the
LD_LIBRARY_PATH setting for uninstalled shared libraries to work. That
does not affect received `args' being empty however.
Maciej
