Re: Problems with signals and illegal instructions in user mode

[Gabe Black]

Thanks for looking into this. Is there any way to fix these problems? IE to tell QEMU to not act like it has coprocessor 1? For that one in particular, there are a lot of binaries out there which already try to use that instruction, and changing them would be difficult or impossible for reasons like checkpointed systems with the existing binary, etc. I'm supposing the fix for SPARC would be to implement that support in QEMU somehow. I might be able to do that? But I'd have to find the time from somewhere :-/ Is there any way to fix the SIGSEGV error code? It sounds like I may just have to make my test more lenient. That's not ideal since functionally it's pretty important that there's really a page there, but I guess when I check in /proc/XXX/maps that will cover it?

Gabe

On Thu, Apr 23, 2020 at 2:39 AM Peter Maydell <address@hidden> wrote:

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