On Thu, 26 May 2022 at 11:01, Peter Maydell <peter.mayd...@linaro.org> wrote: > > On Thu, 26 May 2022 at 09:32, Liviu Ionescu <i...@livius.net> wrote: > > > On 26 May 2022, at 11:20, Peter Maydell <peter.mayd...@linaro.org> wrote: > > > > > > ... can you provide us with > > > a reproduce case (eg the binary you used here)? > > > > Sure. I'll try to attach it to this message, it is only 64K. > > > > The command I used to run the test is in the previous message. > > > > Please confirm that you get the same behaviour on your machine. > > Yes, I can reproduce this. What seems to be happening is that > QEMU decides to do semihosting via gdb, but then crashes because > gdbserver_state.c_cpu is NULL (which in turn is probably because > there is no GDB connected). This is strange given the 'target=native' > in the command line. I'll investigate further...
The failure to honour the 'target=native' option is the result of a commandline parsing weirdness/bug. It happens because your command line specifies two separate '--semihosting-config x=y,x=y...' option groups, and the code was not written to take account of that possibility. So in qemu_semihosting_config_options() it looks for "did the user specify target=something" with the default being 'auto'. This function gets run twice, once per --semihosting-config option you have. So the first time around we set semihosting.enabled to true and semihosting.target to SEMIHOSTING_TARGET_NATIVE. But then the second time around we say "oh, the user didn't specify either enabled or target, so default them to true and SEMIHOSTING_TARGET_AUTO", overwriting the value that got set up by the first call. We should fix this (as well as the bug it reveals in the use of 'target=auto|gdb' when the gdbstub is initialized but no gdb is connected), but in the meantime you can work around it by always providing just one --semihosting-config option, like this: --semihosting-config enable=on,target=native,arg=sample-test,arg=one,arg=two I don't think any of this ought to be target-specific, so perhaps the command line you use for 32-bit arm is slightly different and avoided the bug by good fortune ? thanks -- PMM
