Unable to attach to remote gdbserver

[sherrellbc]

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:

cdtDebugTargetAdapter --server=50000 --config-frozen='{"request": "attach", "target" : {"host":"x.x.x.x", "port":"yyyy"}}'

As well as

cdtDebugTargetAdapter --server=50000 --config-frozen=@config.json

With config.json having contents of:

{
   "request": "attach",
   "target" : {"host":"x.x.x.x", "port":"yyyy"}
}

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:

cdt_1  | /
cdt_1  |  ::ffff:172.18.0.1: WebSocket connection
cdt_1  |  ::ffff:172.18.0.1: Version undefined, subprotocol:
cdt_1  |  ::ffff:172.18.0.1: connected to target
cdt_1  | >> accepted connection from client

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:

--config-frozen='{"request": "attach", "parameters":"x.x.x.x:yyyy"}'
--config-frozen='{"request": "attach", "host":"x.x.x.x", "port":"yyyy"}'
--config-frozen='{"request": "attach", "connectCommands":"target remote x.x.x.x:yyyy"}'

[jonahgraham]

@thegecko do you think you can help @sherrellbc on this?

[thegecko]

@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?

[jonahgraham]

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.

[sherrellbc]

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"

[sherrellbc]

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]

[thegecko]

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

[sherrellbc]

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} "
            }

[sherrellbc]

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.

[jonahgraham]

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.