[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2] gdbstub: fixes cases where wrong threads were reported to
From: |
Alex Bennée |
Subject: |
Re: [PATCH v2] gdbstub: fixes cases where wrong threads were reported to GDB on SIGINT |
Date: |
Thu, 10 Aug 2023 18:30:10 +0100 |
User-agent: |
mu4e 1.11.13; emacs 29.1.50 |
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