[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems with signals and illegal instructions in user mode

From: Gabe Black
Subject: Re: Problems with signals and illegal instructions in user mode
Date: Tue, 21 Apr 2020 20:30:15 -0700

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). You can leave off --gtest_output=... if it's in the way. Those tests should all pass, assuming I didn't mess something up I haven't been able to find. The failures are from:

1. arm/.../inst - not treating a coprocessor access as an illegal instruction when there isn't (shouldn't be?) a coprocessor with that number.
2. arm64/.../addr - Expected error code SEGV_ACCERR (2), but actually got 1 which I think is SEGV_MAPERR, described as "Address not mapped to object.". The page is mapped, it just doesn't have any permissions enabled. When given any permissions, read or write, I think the access succeeds even though it may not have permission for the type of access it's trying. So the two options seem to be the page doesn't look like it's there at all even though it is, or it's completely accessible even if it shouldn't be.
3. sparc/.../inst - "Illegal instruction (core dumped)" when that signal should have triggered a handler I'd registered with sigaction (which works on arm64 at least).
4. x86/.../addr - Same as arm64/...addr


On Tue, Apr 21, 2020 at 12:14 PM Peter Maydell <address@hidden> wrote:
On Fri, 17 Apr 2020 at 12:42, Gabe Black <address@hidden> wrote:
> Hi Peter, have you had a chance to take a look at this test case? Please let me know if you need any other info, precompiled binaries, etc.

I had a look, but it doesn't build:

SHCC build/arm/jni_gem5Op.os
In file included from build/arm/jni_gem5Op.c:41:0:
build/arm/jni_gem5Op.h:2:10: fatal error: jni.h: No such file or directory
 #include <jni.h>
compilation terminated.

I'm running Ubuntu; I had to install the openjdk-11-jdk-headless
package to get a 'javac' binary, and this does seem to have
installed a jni.h (in /usr/lib/jvm/java-11-openjdk-amd64/include)
but your build system presumably hasn't found it.

Is there a more straightforward "just build this code
and run this binary: I expected behaviour X but got
behaviour Y" testcase you can provide? Preferably
one that doesn't involve Java, because trying to debug
JIT code inside QEMU is vastly more painful than working
with simple compiled code...

-- PMM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]