Re: Problems with signals and illegal instructions in user mode

Hi! Thank you for your help! This email is a bit long, but I just want to avoid leaving out something important and wasting your time.

I double checked the version of QEMU I'm running, and it's 4.2, the version Arch installed through pacman a few days ago.

The failing tests are part of a larger code base that would be a big pain for you to set up, so I stripped it down to just the essentials and am going to attempt to send it to you through email. The tarball is ~1.3MB which isn't that big, but it may still not get through. If so I can try sending it to you some other way. Most of that size is from the included googletest unit testing library.

To use it, untar the tarball, and cd into qemu_test_case/util/m5. From there, you can use scons to build the utility and its various unit tests which will run either natively or under QEMU. scons will detect if you have the appropriate QEMU binary available (qemu-${arch}), and will not try to run non-native tests without it.

To build for the various architectures, scons will default to look for (and I have been using) versions of gcc with the following tuples (crosstool-ng configs attached):

aarch64-linux-gnu-

arm-linux-gnueabihf-

sparc64-linux-gnu-

The x86 binaries assume that your native compiler is x86, so it sets the cross compiler prefix to nothing. If you're building on, say, an ARM machine, you should be able to override that by setting x86.CROSS_COMPILE=${the prefix you need} either as an environment variable, or after scons on the command line.

The scons script accepts a few options which the --help describes. If you want to build all versions and exclude running the tests which, as I said, have some problems:

scons --no-test-xml build/

To build a particular version:

scons build/${version}

ie.

scons --no-test-xml build/aarch64/

scons --no-test-xml build/arm/

To build the native binaries (just tests):

scons build/native/

If you have all the compilers set up, a handy sequence to see the result of the tests is:

# Build everything but don't run the tests.

scons --no-test-xml build/

# Build everything (only tests are left), and don't stop if something fails.

scons --keep-going build/

Please let me know if you need to know anything else, and I apologize in advance if I did something dumb :-)

Gabe

On Fri, Apr 10, 2020 at 5:21 AM Peter Maydell <address@hidden> wrote:

On Fri, 10 Apr 2020 at 12:19, Gabe Black <address@hidden> wrote:
>
> I've expanded my set of tests to know include a call mechanism that's based on accesses to a special region of memory, and I'm having problems with that too. I'm trying to use mprotect to block the pages that map to the magic region so that when the utility attempts to access them, it will get a SIGSEGV and I can look at what it tried to do.
>
> Running that test program natively on my x86 workstation works, but I have problems when I run it for aarch64 in qemu. If I mprotect it with the protection set to 0, it acts like it's not there at all (the si_code is for an unmapped area, not access permissions), and if I mprotect it to have any permissions at all, the magic read is allowed to happen without a SIGSEGV even if there are no read permissions.
>
> Is this a fuzzy edge of the system calls QEMU can emulate? I'm hoping to be able to use QEMU to run these test programs quickly with low overhead as part of our test suite, but from my experience with a similar user mode in our own simulator, I understand how getting all these details right can be very hard and not always worth the trouble.

It's hard to say exactly what is going on without a test case, but I
suspect that we may not report the right si_code for unmapped
vs bad permissions. We should however report a SIGSEGV
of some kind for wrong-permissions.

SIGILL for illegal instructions should work: we use this for our
'risu' random-instruction tester:
https://git.linaro.org/people/peter.maydell/risu.git

Not all guest architectures in QEMU are supported to the
same 'quality level' (eg arm should be pretty solid, x86 is less
so, some of the minor architectures can be pretty flaky), so
where functionality requires guest-arch-specific support it may
be buggy. Again, hard to say for certain without specific test cases.
In particular, bugs in 32-bit or 64-bit arm guest handling are something
I'd be interested in fixing.

You don't say what QEMU version you're using: make sure you're using
the most recent QEMU version.

thanks
-- PMM
git grep

From:	Gabe Black
Subject:	Re: Problems with signals and illegal instructions in user mode
Date:	Sat, 11 Apr 2020 02:53:40 -0700