Matheus Branco Borella <dark.ryu....@gmail.com> writes:
> Alex Bennée <alex.ben...@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....@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