vAttach: invalid response causes command to not work about gdbstub

[xobs]

Well, there's a bit more nuance here: the correct response of vAttach is any valid Stop Reason - not just those two.

True, but it's unclear exactly what registers are required, and gdb gets upset if you omit those registers. It also gets grumpy if you don't enumerate all the threads properly, and replying with S00 tells it to ask for that information separately.

[xobs]

(It's also interesting to note that because gdbstub doesn't support having no process active, it necessarily asks "A program is being debugged already. Kill it? (y or n)", but gdbserver supports having no process active, and therefore does not ask that question.)

[daniel5151]

I took a gander at the code, and it seems we're returning a HandlerStatus::Handled instead of a HandlerStatus::DeferredStopReason from the ExtendedMode::vAttach handler:

gdbstub/src/stub/core_impl/extended_mode.rs

Line 31 in 1c5407e

HandlerStatus::Handled

Can you change that line and see if it helps?

[xobs]

A few notes:

1. The correct return for vAttach is S00 (or T00......), which does work!

(gdb) att 2
Attaching to program: E:\Code\Xous\Core\target\riscv32imac-unknown-xous-elf\release\xous-ticktimer, process 2
[remote] Sending packet: $vAttach;2#38
[remote] Packet received: S00
[remote] packet_ok: Packet vAttach (attach) is supported

2. We need to handle qC, and this response must return the PID requested (i.e. we can't unilaterally use FAKE_PID):

FAKE_PID:

[remote] Sending packet: $vAttach;2#38
[remote] Packet received: S00
[remote] packet_ok: Packet vAttach (attach) is supported
[remote] Sending packet: $qC#b4
[remote] Packet received: QCp01.02
/__w/riscv-none-elf-gcc-xpack/riscv-none-elf-gcc-xpack/build/win32-x64/sources/gdb-12.1/gdb/thread.c:530: internal-error: find_thread_ptid: Assertion `inf != nullptr' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y

Actual PID (i.e. 2):

(gdb) att 2
Attaching to program: E:\Code\Xous\Core\target\riscv32imac-unknown-xous-elf\release\xous-ticktimer, process 2
[remote] Sending packet: $vAttach;2#38
[remote] Packet received: S00
[remote] packet_ok: Packet vAttach (attach) is supported
[remote] Sending packet: $qC#b4
[remote] Packet received: QCp02.02
[remote] Sending packet: $Hgp2.2#b1
[remote] Packet received: OK

I've added a new function to MultiThreadBase that allows me to get the current active PID, and with that I'm now able to switch processes by using attach [PID].

The result of this is in #129

[daniel5151]

1. The correct return for vAttach is S00 (or T00......), which does work!

Well, there's a bit more nuance here: the correct response of vAttach is any valid Stop Reason - not just those two.

2. We need to handle qC, and this response must return the PID requested (i.e. we can't unilaterally use FAKE_PID):

Indeed, I'm not surprised that GDB gets angry if you give it back a thread-id it's not expecting...

---

Will continue the discussion over on #129 itself

[daniel5151]

Closed via #129