blob: 2eb46dcdb296a847f782d52ea330a6632c5d5405 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
|
debug: 0.914
arm: 0.834
graphic: 0.801
performance: 0.792
device: 0.707
mistranslation: 0.695
architecture: 0.646
vnc: 0.643
network: 0.564
i386: 0.535
semantic: 0.519
VMM: 0.499
x86: 0.481
ppc: 0.477
assembly: 0.432
risc-v: 0.407
PID: 0.396
hypervisor: 0.385
permissions: 0.385
boot: 0.382
kernel: 0.378
socket: 0.368
peripherals: 0.365
register: 0.320
TCG: 0.269
user-level: 0.264
virtual: 0.262
files: 0.242
KVM: 0.182
qemu-system-arm: thumb2: vector table branch instruction not followed
Description of problem:
When an undefined instruction is hit and causes an exception that causes a jump to the undef vector at 0x04; translation of the branch instruction found there appears to fail since instead of branching to the handler it steps to the next instruction - the next entry in the vector table, translates that, and on stepping once again moves to the next entry in the vector table. Eventually it steps out of the table and (re)enters the _start subroutine pointed to by vector 0x0.
Steps to reproduce:
This is related to issue #2542 in as much as I am hunting down failures in the picolibc 1.8.6 test suite on Debian. After fixing issues such as the failure to enable the MMU and some others via incorporating upstream commits I'm left with 10 tests, all for exception handling, that result in meson (build system) TIMEOUT instead of EXPECTEDFAIL. All of these tests should fail instantly and cause Qemu to exit but it continues - apparently spinning in an endless loop as described above until meson kills it.
Creating a small reproducer has proved challenging and nigh impossible (for me) - even identifying the crux as described here has taken 4 days. However with the help of `qemu-system-arm -d in_asm,op,out_asm ...` and `gdb-multiarch` I believe I may have produced a focused report that will help figure this out.
#
Additional information:
Since this is hard to debug I can give remote ssh access via `tmate` to directly control the debug session if necessary.
|