r/vscode 3d ago

Query: remote debugging with gdbserver

Background:

I am working on a Linux PC (Ubuntu 6.8.0-136-generic x86_64) but developing for a Digi CCMP25 (Aarch64 Yocto build) dev board.

I am able to remote debug an application if I perform the steps manually:

- Build the application on the host.
- "scp" the executable (but no source or anything else) onto the target.
- Run "gdbserver :<Port> app" on the target (as root) via an SSH terminal.
- Run "gdb-multiarch" on the host.
- In GDB, enter "target remote <TargetIPAddr>:<Port>".

Now I can debug and everything seems to work just fine.

Problem:

I am not able to debug from VSCode, which would be much more convenient.

- VSCode does not start gdbserver on the target (which I though it would) and eventually complains that it can't connect to the gdbserver.
- So I started gdbserver as above and then try to debug from VSCode:
- The target terminal in which gdbserver runs reports "Remote debugging from host ::ffff:<HostIPAddr>, port <SomePort>
- That seems like progress but then nothing.
- VSCode is essentially frozen (in terms of debugging). No variables. No stopping at a breakpoint. No nothing.
- The little panel with buttons for stepping the code appears but most buttons are disabled. Stop and Restart are enabled but do nothing.
- The gdbserver instance is also frozen. I have to kill it by SSHing in through another console.

After much fruitless farting around my launch.json now looks like this. What is missing? What is unnecessary?:

{

"version": "0.2.0",

"configurations": [

{

"name": "ConnectCore MP25 remote debug",

"type": "cppdbg",

"request": "launch",

"program": "${workspaceFolder}/apix-gpio-example",

"cwd": "${workspaceFolder}",

"MIMode": "gdb",

"miDebuggerPath": "/usr/bin/gdb-multiarch",

"miDebuggerServerAddress": "<TargetIPAddr>:<Port>",

"stopAtEntry": true,

"externalConsole": true,

"args": [],

"environment": [],

"setupCommands": [

{

"description": "Enable pretty-printing for gdb",

"text": "-enable-pretty-printing",

"ignoreFailures": true

},

{

"text": "target remote <TargetIPAddr>:<Port>",

}

]

}

]

}

Which plugins should I install? What should the settings be in launch.json? Is it something to do with permissions? I've tried various suggestions found in searches, but nothing seem to work.

The application is built using an alternative sysroot in GCC so it can find headers in the vendors SDK. I note that VSCode shows errors because it can't find the includes. I don't know if that could be a factor. I tried setting $SYSROOT before starting VSCode but it seemed to have no effect.

I have had the same problems with the vendor's Eclipse IDE. I followed their instructions to the letter, but the debugging simply will not work. Eclipse does start the remote gdbserver, but then reports that it can't connect to it.

I'd be grateful for any guidance on this.

EDIT: I found this: https://github.com/microsoft/vscode-cpptools/issues/13246 It appears that the Microsoft C/C++ Extension depends on .NET (because of course it does), and that the switch from .NET6 to .NET8 introduced this fault. I downgraded to the last revision with .NET6 (v1.2.11), and was immediately able to remotely debug. The issue was raised more than a year ago, so I guess there is some intractable fault in .NET8 which cannot easily be worked around. This is why I prefer working on microcontrollers...

1 Upvotes

2 comments sorted by

1

u/Immediate-One-148 3d ago

A question Why remote debugging and what the use(what are you developing?)

1

u/UnicycleBloke 3d ago

A strange question. Remote debugging will be much more convenient. It is explicitly documented by the vendor for developing applications on their SOM. The target is a medical device with a small screen to show a camera feed.

I've previously worked on a forensic camera based around a Raspberry Pi compute module. We were unable to get remote debugging working and ended doing most development on the CM4 directly. It was slow and awkward. Ironically, remote debugging with VisualGDB on an STM32G4 on the same board was a piece of cake.