Open sherrellbc opened 1 year ago
@thegecko do you think you can help @sherrellbc on this?
@jonahgraham I asked for this issue to be raised here for visibility :)
The only place I can see a reference to arg
is here:
https://github.com/eclipse-cdt-cloud/cdt-gdb-adapter/blob/main/src/GDBBackend.ts#L242
I assume this is because it expects a program to be set here:
https://github.com/eclipse-cdt-cloud/cdt-gdb-adapter/blob/main/src/GDBTargetDebugSession.ts#L278
@jonahgraham Is program
required when connecting to a remote gdbserver? If not, this needs a guard.
@sherrellbc can you try a config including a program
entry and also confirm the debug configuration you are using in VS Code, too?
program
is required - see adapter declaration and package.json which will give a warning in VSCode when using cdt-gdb-vscode:
If there are use cases that program isn't needed I would be happy to review a PR that addressed that. It also sounds like we could do with a PR that gives a better error message on program
being missing.
Within VSCode, my launch.json
contains:
"version": "0.2.0",
"configurations": [
{
"name": "Attach WebSocket",
"type": "arm-debug",
"request": "attach",
"address": "ws://localhost:50001",
"pathMapping": {
"/home": "${workspaceFolder}"
}
}
]
and the adapter config is:
cdtDebugTargetAdapter --server=50000 --config-frozen='{"request": "attach", "program": "/home/hello", "host":"x.x.x.x", "port":"yyyy"}'
With a websockify proxy listening on 50001 and forwarding to 50000. With the addition of program
I now see in VSCode a different failure where it says
"To open a remote debug connection, you need to specify what serial device is attached to the remote system"
Actually, after updating the config string to use target:{host, port}
it started to work in some ways. I can now attach to the remote target but am not able to use breakpoints. The test program I have will just run through and exit, never hitting any breakpoints.
... gdb ...
For help, type "help".
Type "apropos word" to search for commands related to "word".
GDB unhandled notify: tsv-created: {"name":"trace_timestamp","initial":"0"}
Reading /lib/ld-linux-aarch64.so.1 from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading /lib/ld-linux-aarch64.so.1 from remote target...
Reading /lib/7648e0ab1141e21a749711cde7a7b250b9e1d3.debug from remote target...
Reading /lib/.debug/7648e0ab1141e21a749711cde7a7b250b9e1d3.debug from remote target...
Reading /usr/lib/debug//lib/7648e0ab1141e21a749711cde7a7b250b9e1d3.debug from remote target...
Reading /usr/lib/debug/lib//7648e0ab1141e21a749711cde7a7b250b9e1d3.debug from remote target...
Reading target:/usr/lib/debug/lib//7648e0ab1141e21a749711cde7a7b250b9e1d3.debug from remote target...
0x0000fffff7fcd100 in ?? () from target:/lib/ld-linux-aarch64.so.1
connected to remote target x.x.x.x:yyyy
Reading /lib/aarch64-linux-gnu/libc.so.6 from remote target...
Reading /lib/aarch64-linux-gnu/b30ba2c0f618615a8d32d86813718bb2fdb567.debug from remote target...
Reading /lib/aarch64-linux-gnu/.debug/b30ba2c0f618615a8d32d86813718bb2fdb567.debug from remote target...
Reading /usr/lib/debug//lib/aarch64-linux-gnu/b30ba2c0f618615a8d32d86813718bb2fdb567.debug from remote target...
Reading /usr/lib/debug/lib/aarch64-linux-gnu//b30ba2c0f618615a8d32d86813718bb2fdb567.debug from remote target...
Reading target:/usr/lib/debug/lib/aarch64-linux-gnu//b30ba2c0f618615a8d32d86813718bb2fdb567.debug from remote target...
[Inferior 1 (process 429695) exited with code 0101]
Please check your pathMapping
is correct, it should reflect the build directory structure used when the binary was built (remote) and your local source structure.
The binary also needs to be built with debug symbols of course
The test binary is just a single file, and so on the remote system I have built it in /tmp/hello
(built with debug symbols of course). And my VSCode pathMapping reflects this:
"pathMapping": {
"/tmp/": "${workspaceFolder} "
}
Turns out the pathMapping is somewhat strict. The extra space at the end of the local path side was causing the trouble. The following works:
"pathMapping": {
"/tmp/": "${workspaceFolder}/"
}
thanks @thegecko.
Also, @jonahgraham its not inconceivable that someone might be interested in debugging a remote target for which you do not have the program for. Or maybe you have the program but it doesnt have debug symbols, or you have sources but can't rebuild it for whatever reason. It is certainly less common, but in general gdb allows you to connect to a remote gdbserver instance and debug whatever it is attached to. Having debug symbols and source-level debug info is helpful, but not required.
It is certainly less common, but in general gdb allows you to connect to a remote gdbserver instance and debug whatever it is attached to. Having debug symbols and source-level debug info is helpful, but not required.
I think the correct fix would be to leave the warning and handle the case. I have submitted #262 to address this case.
When attempting to provide a config that would instruct the adapter to attach to a remote GDB server it seems to fail. I tried the following:
As well as
With
config.json
having contents of:but again, no dice. I am attempting to use the plugin with Arm's Embedded Debugger for VSCode. When I run with the above configuration I am met with an error dialog in VSCode that simply states "arg is not iterable". From the cdt-gdb-adapter instance I see the following:
On my test gdbserver instance I do not see any client connections coming in. It is somewhat unclear if the issue is in this plugin or within Arm's VSCode plugin. However, there are no examples in this repo for how to use the
attach
request so my formation of the config is somewhat contrived based on my interpretation of the sources. Other formats I tried: