This turns out to be nothing to do with setend. We're doing something wrong emulating the following nasty hack: https://github.com/bavison/arm-mem/blob/master/architecture.S
.arm architecture: sub pc, pc, #1 @ is an interworking branch on ARMv7, not ARMv6 and a1, a4, a1 @ second word interpreted as 'B .+0xA' if Thumb mov a1, #6 bx lr .thumb mov a1, #7 bx lr so after the 'sub pc, pc, #1' (which in my debug trace is at address 0xb6f086dc) QEMU next tries to execute from 0xb6f086e2 in ARM mode, which is neither of the two expected outcomes. As it happens we hit an undefined instruction pretty much immediately afterwards: 0xb6f086e2: 0006e003 andeq lr, r6, r3 0xb6f086e6: ff1ee3a0 undefined instruction 0xff1ee3a0 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1625295 Title: qemu-arm dies with libarmmem inside ld.so.preload Status in QEMU: New Bug description: When running raspbian inside qemu,the user has to first comment out the following line from /etc/ld.so.conf: /usr/lib/arm-linux-gnueabihf/libarmmem.so Will future qemus will be able to work without changine /etc/ld.so.conf ? To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1625295/+subscriptions