1 files changed, 66 insertions, 0 deletions
diff --git a/results/classifier/108/other/1724485 b/results/classifier/108/other/1724485
new file mode 100644
index 000000000..caf276f38
--- /dev/null
+++ b/results/classifier/108/other/1724485
@@ -0,0 +1,66 @@
+debug: 0.870
+semantic: 0.846
+performance: 0.772
+files: 0.717
+device: 0.670
+other: 0.635
+graphic: 0.621
+network: 0.457
+socket: 0.447
+PID: 0.438
+permissions: 0.416
+boot: 0.372
+vnc: 0.335
+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.
+
+