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
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
|
debug: 0.870
arm: 0.846
semantic: 0.846
performance: 0.772
ppc: 0.752
mistranslation: 0.730
files: 0.717
assembly: 0.707
architecture: 0.676
device: 0.670
peripherals: 0.640
graphic: 0.621
kernel: 0.584
x86: 0.581
user-level: 0.570
network: 0.457
socket: 0.447
virtual: 0.444
PID: 0.438
permissions: 0.416
i386: 0.396
risc-v: 0.385
boot: 0.372
VMM: 0.370
TCG: 0.337
vnc: 0.335
register: 0.332
hypervisor: 0.313
KVM: 0.238
Invalid assertion in arm_read_memory_func
Hi,
I think there is an invalid assertion in arm_read_memory_func:
assert(info->endian == BFD_ENDIAN_LITTLE)
I face it in the following use case: target armeb-linux (I use qemu user mode), -d in_asm -cpu any.
At some point during program startup, glibc's _dl_new_object calls strlen, which is written in thumb2 mode (armv6t2). So print_insn_arm() calls arm_read_memory_func() with length==2, and info->flags == INSN_ARM_BE32, and the assert is false.
If I remove the assert, execution continues OK.
With the assert, I get the error message from the assert, and qemu then stalls.
Can you confirm the assert can be removed? Or if not, explain me how to avoid/fix the subsequent qemu stall?
Thanks
The tarball contains:
scoped1.exe
etc/ld.so.cache
lib/libm.so.6
lib/libstdc++.so.6
lib/lib.c.so.6
lib/ld-linux-armhf.so.3
lib/libgcc_s.so.1
I can reproduce the problem with qemu-2.10.1:
qemu-armeb -E LD_LIBRARY_PATH=$PWD/lib -cpu any -R 0 -d in_asm -L $PWD $PWD/scoped1.exe
Removing '-d in_asm' works OK, because the offending assert is triggered while disassembling.
BTW, the program (scoped1.exe) does abort, it is a GCC testcase I was trying to debug ;-)
Removing the assert lets execution continue, but the disassembly is incorrect. Without the assert, I see:
IN: strlen
0x40a1a880: f000 f890 bl 0x40a1a9a4
0x40a1a884: 4502 cmp r2, r0
but strlen normally starts with a pld instruction.
So probably print_insn_arm needs also a change like
given = (b[1]) | (b[0] <<8)<<16 | given;
instead of
given = (b[1]) | (b[0] <<8)|(given << 16);
This should be fixed in QEMU master by commits 6cd61517fb5217098, 7bcdbf51eeb674e4.
|