When connecting from Windows VS Code to gdbserver on Linux, "remote register badly formatted" error
Running VSCode 1.97.2 on Windows 10 x64. The project is a C++ one targeting Linux, x64. The launch settings go:
{
"type": "gdb",
"request": "attach",
"name": "Attach to gdbserver",
"executable": "${workspaceFolder}/foo",
"target": "sandbox:9999",
"remote": true,
"cwd": "${workspaceRoot}"
}
On the Linux box ("sandbox"), I start gdbserver: gdbserver :9999 ./foo
If I try to debug from VS Code, I get the following error:
Failed to attach: Remote register badly formatted: T0506:0000000000000000;07:20e5ffffff7f0000;10:9030fdf7ff7f0000;thread:2b810;core:1; here: 00000000;07:20e5ffffff7f0000;10:9030fdf7ff7f0000;thread:2b810;core:1; (from target-select remote sandbox:9999)
Some more diagnostics. If I run like this: there is the following output in the debug console window:
"R:\dev\Foo/foo": not in executable format: File format not recognized warning: limiting remote suggested packet size (18431 bytes) to 16384 warning: while parsing target description (at line 8): Cannot add typed field "CF" to flags warning: Could not load XML target description; ignoring
Then following some online guidance, I've added gdbpath to the launch settings: "gdbpath": "E:\\cygwin64\\bin\\gdb.exe" and got a different set of output, followed by the same error:
warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration of GDB. Attempting to continue with the default i386:x86-64 settings.
Reading symbols from R:\dev\Foo/foo... Warning: 'set target-async', an alias for the command 'set mi-async', is deprecated. Use 'set mi-async'.
Warning: /cygdrive/r/dev/Foo/R:\dev\Foo: No such file or directory. undefinedBFD: reopening /cygdrive/r/dev/Foo/R:\dev\Foo/foo: No such file or directory warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration of GDB. Attempting to continue with the default i386:x86-64 settings.
warning: Architecture rejected target-supplied description
So it looks like VSCode's extension doesn't talk to gdbserver directly, it talks to gdb which in turn talks to gdbserver. I wonder what the protocol is - is it a socket? If so, can it be remoted?