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); ** Attachment added: "qemu-bug-1724485.tar.xz" https://bugs.launchpad.net/qemu/+bug/1724485/+attachment/4974653/+files/qemu-bug-1724485.tar.xz -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1724485 Title: Invalid assertion in arm_read_memory_func Status in QEMU: New Bug description: 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 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1724485/+subscriptions
