Re: AArch64 semihosting?

[Peter Maydell]

On Thu, 26 May 2022 at 11:01, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Thu, 26 May 2022 at 09:32, Liviu Ionescu <ilg@livius.net> wrote:
> > > On 26 May 2022, at 11:20, Peter Maydell <peter.maydell@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