Hi! I work on an open source simulator called gem5 (
www.gem5.org), and I'm trying to use QEMU to validate a little binary we have which runs inside the simulator and lets software/users within the simulation request services from the simulator itself.
The utility program, called "m5" for historical reasons, can make those requests in several ways, but the one I'm trying to test is by using magical instructions which are normally undefined, but which the simulator hooks into. I wrote a test program which takes the actual call sight and wraps it in some testing code which attempts to handle the SIGILL, capture information about where it happened, and then use a siglongjmp to go back to somewhere sane to analyze that info and make sure the right instruction triggered the SIGILL, that it was requesting the right service, etc. This test code is intended to run on real or "real" hardware which won't have an implementation for the magic instructions, and since QEMU should fit and should be easy to run and should be trustworthy as far as implementing the ISA correctly, etc., I wanted to verify within that.
Unfortunately, depending on what target architecture I use, how QEMU actually responds is a little all over the map.
qemu-aarch64 - Works as expected. There is a SIGILL, it happens in the right place, and is caught correctly.
qemu-arm - No illegal instruction. The instruction is:
mcr 1, 1, r0, cr3, cr0, {0}
which I *think* should count as illegal because it uses coprocessor 1, and to my knowledge there isn't a coprocessor 1 typically. Does QEMU emulate one there, and can I tell it not to?
qemu-arm (thumb binary) - A SIGILL happens, but the si_addr field of the siginfo_t is not actually at the instruction I expect. This could be because the assembly code it's written with doesn't handle interworking branches correctly? I think despite flags telling the compiler to use thumb it used ARM anyway, except for the little call sight which is in thumb assembly.
qemu-sparc - A SIGILL happens, but my earlier call to sigaction seems to have been ignored, and the default handler fires killing the binary.
Other than the little binary stub and a macro which extracts some info from si_addr after the misbehaving part, these versions all use the same code. I've had some trouble trying this on actual hardware and so can't rule out a bug in the implementation, but I suspect something funny is happening in QEMU.
Any help is appreciated!
Gabe