On 28 October 2014 13:54, Liviu Ionescu <i...@livius.net> wrote: > >> Do you have a test binary (plus qemu command line) you >> can send me? > > sure: https://dl.dropboxusercontent.com/u/78151643/minimal.elf
> exactly the same binary, with 2.1.50: > > ilg-mbp:build ilg$ > /Users/ilg/Work/NoBackup/qemu/qemu.git/arm-softmmu/qemu-system-arm -machine > lm3s6965evb -nographic -monitor null -serial null -semihosting -m 513M > -kernel qemu_osx_aep_gcc_minimal_Debug/minimal.elf > qemu: Unsupported SemiHosting SWI 0x00 > R00=00000000 R01=00000000 R02=00000000 R03=00000000 > R04=00000000 R05=00000000 R06=00000000 R07=200ffed8 > R08=00000000 R09=00000000 R10=00000000 R11=00000000 > R12=00000000 R13=200ffed8 R14=000022c5 R15=0000157c > PSR=60000173 -ZC- T svc32 > Abort trap: 6 Thanks. I've identified what's happening here, and it's not a bug in QEMU as such. The 'lm3s6965evb' model is of a microcontroller with 64KB of SRAM, so valid RAM is only from 0x20000000 to 0x20010000, but your binary is trying to use the area beyond that as RAM as well, and is therefore misbehaving. (We ignore any attempt to specify RAM size via the command line -m switch, so your '-m 513M' has no effect). You can turn on tracing of what QEMU executes like this: ./build/x86/arm-softmmu/qemu-system-arm -machine lm3s6965evb -display none -semihosting -kernel ~/Downloads/minimal.elf -d in_asm,cpu,exec -singlestep and you can see (note that the register dumps here are always for the point *before* the insn we've just printed, as you can tell from the values of R15): IN: _ZN3hal7cortexm4diag11SemiHosting4BKPTEiPvS3_ 0x00001568: af00 add r7, sp, #0 Trace 0x7f4286560710 [00001568] _ZN3hal7cortexm4diag11SemiHosting4BKPTEiPvS3_ R00=00000004 R01=00000000 R02=00000000 R03=00000000 R04=00000000 R05=00000000 R06=00000000 R07=200ffef0 R08=00000000 R09=00000000 R10=00000000 R11=00000000 R12=00000000 R13=200ffed8 R14=000022c5 R15=00001568 PSR=60000173 -ZC- T svc32 ---------------- IN: _ZN3hal7cortexm4diag11SemiHosting4BKPTEiPvS3_ 0x0000156a: 60f8 str r0, [r7, #12] Trace 0x7f4286560750 [0000156a] _ZN3hal7cortexm4diag11SemiHosting4BKPTEiPvS3_ R00=00000004 R01=00000000 R02=00000000 R03=00000000 R04=00000000 R05=00000000 R06=00000000 R07=200ffed8 R08=00000000 R09=00000000 R10=00000000 R11=00000000 R12=00000000 R13=200ffed8 R14=000022c5 R15=0000156a PSR=60000173 -ZC- T svc32 ---------------- IN: _ZN3hal7cortexm4diag11SemiHosting4BKPTEiPvS3_ 0x0000156c: 60b9 str r1, [r7, #8] Trace 0x7f42865607e0 [0000156c] _ZN3hal7cortexm4diag11SemiHosting4BKPTEiPvS3_ R00=00000004 R01=00000000 R02=00000000 R03=00000000 R04=00000000 R05=00000000 R06=00000000 R07=200ffed8 R08=00000000 R09=00000000 R10=00000000 R11=00000000 R12=00000000 R13=200ffed8 R14=000022c5 R15=0000156c PSR=60000173 -ZC- T svc32 ---------------- IN: _ZN3hal7cortexm4diag11SemiHosting4BKPTEiPvS3_ 0x0000156e: 607a str r2, [r7, #4] Trace 0x7f4286560870 [0000156e] _ZN3hal7cortexm4diag11SemiHosting4BKPTEiPvS3_ R00=00000004 R01=00000000 R02=00000000 R03=00000000 R04=00000000 R05=00000000 R06=00000000 R07=200ffed8 R08=00000000 R09=00000000 R10=00000000 R11=00000000 R12=00000000 R13=200ffed8 R14=000022c5 R15=0000156e PSR=60000173 -ZC- T svc32 ---------------- IN: _ZN3hal7cortexm4diag11SemiHosting4BKPTEiPvS3_ 0x00001570: 68f8 ldr r0, [r7, #12] Trace 0x7f4286560900 [00001570] _ZN3hal7cortexm4diag11SemiHosting4BKPTEiPvS3_ R00=00000004 R01=00000000 R02=00000000 R03=00000000 R04=00000000 R05=00000000 R06=00000000 R07=200ffed8 R08=00000000 R09=00000000 R10=00000000 R11=00000000 R12=00000000 R13=200ffed8 R14=000022c5 R15=00001570 PSR=60000173 -ZC- T svc32 ---------------- IN: _ZN3hal7cortexm4diag11SemiHosting4BKPTEiPvS3_ 0x00001572: 68bb ldr r3, [r7, #8] Trace 0x7f4286560990 [00001572] _ZN3hal7cortexm4diag11SemiHosting4BKPTEiPvS3_ R00=00000000 R01=00000000 R02=00000000 R03=00000000 R04=00000000 R05=00000000 R06=00000000 R07=200ffed8 R08=00000000 R09=00000000 R10=00000000 R11=00000000 R12=00000000 R13=200ffed8 R14=000022c5 R15=00001572 PSR=60000173 -ZC- T svc32 ---------------- Your stack is in invalid memory, which is treated as "writes ignored, reads as zeros". So we get the correct r0 value on entry, but the code stores it to the (invalid) stack and then when it tries to read it back it gets zero, which is incorrect. It's just a coincidence that the first thing your binary does that relies on a working stack happens to involve semihosting. I suggest you relink your binary to fit in the 64K of RAM this board has. (There's also flash at address zero.) thanks -- PMM
