Re: [PATCH v2] gdbstub: fixes cases where wrong threads were reported to GDB on SIGINT

["Alex Bennée" <alex.bennee@linaro.org>]

Matheus Branco Borella <dark.ryu.550@gmail.com> writes:

> Alex Bennée <alex.bennee@linaro.org> writes:
>> Can gdb switch which packet sequence it uses to halt and restart
>> threads?
>
> Yes, but the way it does it does not trigger the behavior I was concerned 
> about. GDB falls back to the old sequence when either (1) the target does not
> support the vCont command it's trying to send or (2) you step backwards. In both
> cases, though, whenever it does fall back, it will first send an Hc packet 
> before continuing or stepping, which means we won't ever see a sequence such as
> ["Hc", "vCont;c:*", "c"]. This means, in short, that, while the shortcoming does
> exist in the code, GDB never actually triggers it.
>
>> The test I would like see is pretty much your test case
>> 
>>  - load a multi-threaded program
>>  - wait until threads running
>>  - pause
>>  - resume thread
>>  - check resumed thread was the right one
>
> What I have here should be pretty much that. 
>
> Is there something else you think I'm missing?
>
> ---
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1725
>
> This fix is implemented by having the vCont handler set the value of
> `gdbserver_state.c_cpu` if any threads are to be resumed. The specific CPU
> picked is arbitrarily from the ones to be resumed, but it should be okay, as all
> GDB cares about is that it is a resumed thread.
>
> Signed-off-by: Matheus Branco Borella <dark.ryu.550@gmail.com>

Arg the commit message is in the --- discard section.

Queued to for-8.1/misc-fixes, thanks.

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro