Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to attach to remote gdbserver #261

Open
sherrellbc opened this issue Apr 11, 2023 · 9 comments
Open

Unable to attach to remote gdbserver #261

sherrellbc opened this issue Apr 11, 2023 · 9 comments

Comments

@sherrellbc
Copy link

sherrellbc commented Apr 11, 2023

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 [email protected]

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
Copy link
Contributor

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

@thegecko
Copy link
Contributor

thegecko commented Apr 12, 2023

@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
Copy link
Contributor

program is required - see adapter declaration and package.json which will give a warning in VSCode when using cdt-gdb-vscode:

image

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
Copy link
Author

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
Copy link
Author

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
Copy link
Contributor

thegecko commented Apr 12, 2023

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
Copy link
Author

sherrellbc commented Apr 12, 2023

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
Copy link
Author

sherrellbc commented Apr 12, 2023

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 added a commit to jonahgraham/cdt-gdb-adapter that referenced this issue Apr 13, 2023
There is no strict need to have a program passed to GDB when
attaching (remote or local). Either the program can be downloaded
from the remote or otherwise read by GDB, or if not possible
then GDB can do symbol-free debugging.

Previously in eclipse-cdt-cloud#228 some work was done to better error when
program was not specified. This change loosens the restrictions
slightly. If the program is not specified, it is still a warning
in VSCode because of
[package.json](https://github.com/eclipse-cdt-cloud/cdt-gdb-vscode/blob/22a9f1048f9030689ed1f5f2b3e5d5e48df9047d/package.json#L205-L207)

See this comment for how it is presented to a user:
eclipse-cdt-cloud#261 (comment)

Part of eclipse-cdt-cloud#261
@jonahgraham
Copy link
Contributor

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.

jonahgraham added a commit to jonahgraham/cdt-gdb-adapter that referenced this issue Apr 21, 2023
There is no strict need to have a program passed to GDB when
attaching (remote or local). Either the program can be downloaded
from the remote or otherwise read by GDB, or if not possible
then GDB can do symbol-free debugging.

Previously in eclipse-cdt-cloud#228 some work was done to better error when
program was not specified. This change loosens the restrictions
slightly. If the program is not specified, it is still a warning
in VSCode because of
[package.json](https://github.com/eclipse-cdt-cloud/cdt-gdb-vscode/blob/22a9f1048f9030689ed1f5f2b3e5d5e48df9047d/package.json#L205-L207)

See this comment for how it is presented to a user:
eclipse-cdt-cloud#261 (comment)

Part of eclipse-cdt-cloud#261
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants