Re: Problems with signals and illegal instructions in user mode

[Peter Maydell]

On Wed, 22 Apr 2020 at 04:30, Gabe Black <address@hidden> wrote:
>
> Sure, no problem. I'm not super familiar with Java so I don't know what's 
> going wrong there, but fortunately that's all incidental to what I need help 
> with. If you run this build command:
>
> scons --keep-going build/arm/test/result/call_type/inst.xml 
> build/arm64/test/result/call_type/addr.xml 
> build/sparc/test/result/call_type/inst.xml 
> build/x86/test/result/call_type/addr.xml
>
> that will run the tests that are failing. If you want to see the command line 
> they're being run with, add --verbose. That will tell you how I'm expecting 
> to run them with qemu (arch flavor, sysroot).

FWIW, this doesn't work on Ubuntu with Ubuntu's packaged cross compilers:

$ scons --verbose --keep-going build/arm/test/result/call_type/inst.xml
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
qemu-arm -L / -- build/arm/test/bin/call_type/inst
--gtest_output=xml:build/arm/test/result/call_type/inst.xml
build/arm/test/bin/call_type/inst: error while loading shared
libraries: libstdc++.so.6: cannot open shared object file: No such
file or directory
scons: *** [build/arm/test/result/call_type/inst.xml] Error 127
scons: done building targets (errors occurred during build).

It looks like you're assuming that the output of the cross compiler
-print-sysroot option is a valid sysroot for QEMU, which I guess it isn't
necessarily. I had to manually run QEMU and fix up the -L option
to point at /usr/arm-linux-gnueabihf.

Anyway:

arm/.../inst:
-------------

The reason you're not seeing a SIGILL here is because
you're using coprocessor number 1. That (together with coprocessor
number 2) is the old FPA floating point unit. QEMU implements
emulation of this so it can support (very) old binaries that
used it or which relied on the Linux kernel's NWFPE emulation
of it. I would expect that you can repro this test failure on
real 32-bit Linux hardware which has the FPE_NWFPE config option
enabled (which will require also OABI_COMPAT and !THUMB2_KERNEL).
The solution here is for you not to use a copro number
that's already been used by somebody (maybe try the UDF
insn instead?)

sparc/.../inst:
---------------

I don't have a sparc cross compiler to hand, but I bet that if
you add '-d unimp' to your QEMU options you'll see it warning
you that setup_rt_frame and do_rt_sigreturn are not implemented.
(That is, QEMU's 32-bit sparc signal handling is just missing
pieces because we don't have anybody who's cared enough
about it to implement it. It would not be an enormous job to
add the support.)

arm64/.../addr and x86/.../addr:
--------------------------------

This is a bug/missing feature where we report all SIGSEGV as
SEGV_MAPERR because the point where we generate the SIGSEGV
is somewhat far removed from the original host SIGSEGV and
we've lost track of the original si_code.

thanks
-- PMM