vAttach: invalid response causes command to not work

[xobs]

The vAttach command appears to respond with an empty packet, which makes gdb think that it is not a supported command:

(gdb) att 3
A program is being debugged already.  Kill it? (y or n) y
[remote] Sending packet: $vKill;1#6e
[remote] Packet received: OK
[remote] packet_ok: Packet vKill (kill) is supported
Attaching to process 3
[remote] Sending packet: $vAttach;3#39
[remote] Packet received:
[remote] packet_ok: Packet vAttach (attach) is NOT supported
This target does not support attaching to a process
(gdb)

It looks like the response should be a T packet. When using gdbserver on Linux:

(gdb) attach 527
Attaching to process 527
[remote] Sending packet: $vAttach;20f#ce
[remote] Packet received: T0006:a0faeb5ce87f0000;07:30086b64ff7f0000;10:f418dc5ce87f0000;thread:p20f.20f;core:15;
[remote] packet_ok: Packet vAttach (attach) is supported
[remote] Sending packet: $qXfer:exec-file:read:20f:0,1000#e1
[remote] Packet received: l/usr/bin/bash
[remote] Sending packet: $qC#b4
...

[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

[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.

[daniel5151]

Closed via #129