Debugging Custom Analyzer with VS Code on Linux (GDB)

Support
1

I am trying to debug a custom logic analyzer shared library (.so) via VSCode and GDB with the Logic 2 .appimage.

I have built my shared library with symbols using CMakeLists.txt : set(CMAKE_BUILD_TYPE Debug)

I can successfully attach to the running module outside of VSCode using gdb attach and setting the PID to the correct process using this post:

ps ax | grep Logic | grep type=renderer

This gives me the correct PID. After I load my custom analyzer on a captured signal, I run lsof -p <pid above> | grep <name of lib> to confirm its loaded.

I can’t seem to get my vscode launch.json configuration correct to utilize gdb and attach and step through and break on breakpoints.

So far, I have a launch.json config that looks like this:

{
    "configurations": [
        {
            "name": "(gdb) Launch Logic and gdb attach to child proc",
            "type": "cppdbg",
            "request": "attach",
            "program": "<PATH_TO_LOGIC.appimage>",
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true,
                },
                {   
                "description":"In this mode GDB will be attached to both processes after a call to fork() or vfork().",
                "text": "-gdb-set detach-on-fork off",
                "ignoreFailures": true
                },
                {   "description": "The new process is debugged after a fork. The parent process runs unimpeded.",
                    "text": "-gdb-set follow-fork-mode child",
                    "ignoreFailures": true
                }
            ]
        }
    ],
    "version": "2.0.0"

I tried adding the logic appimage path to “program”, not sure if that’s correct.

I just cant get the breakpoints to work in vscode
image
Any ideas?

2

Sorry for the trouble! I’ve tested this flow myself on Linux when I wrote the documentation. I’m not quite sure why it’s not working, but here are a few things to check.

First off we added a much easier way to find the correct PID. Details in our readme here. (I just added a screenshot to the readme)

It’s a good idea to double check that that PID matches the one produced by your command.

next, could you test vanilla gdb debugging as described in our readme here?

That readme mentions a ptrace permissions error you might be running into. The same issue is documented in VS code’s attach functionality for Linux here:

Also VS Code requires the executable path even when using attach, but the path you’re using won’t work. The AppImage binary simply loads a read only filesystem then launches the Logic binary, which then launches more instances of the Logic binary. I suggest unpacking the AppImage, then running the Logic binary directly. You can also give the real path to VS Code.

To extract our app image (or any app image) run it with --appimage-extract This will create a folder called squashfs-root I believe, and inside that you will find the Logic binary, which you can run directly.

if you still have trouble with it, let me know, and I’ll switch over to Linux and run through this again to make sure everything is still working.

3

Yes GDB works outside of vscode, so I think the PID is right. I’m able to step through and print whatever I need to check.

I made sure ptrace permission line was ran.

At this point I’m just having issues with VS Code + gdb. I’m hoping to be able to come up with some kind of workflow with having Logic running and just pressing f5 to attach.

I began unpacking the appimage earlier today but I got distracted with a meeting and other things, I’ll target the logic binary inside the squashfs and see if that works.

4

@markgarrison Targetting the binary inside the appimage did the trick!

Thanks for your help.

launch.json that worked - edit <PATH_TO_SQUASHFS_ROOT> for your path. It will ask for PID.

{
    "configurations": [
        {
            "name": "gdb Attach to Logic 2",
            "type": "cppdbg",
            "request": "attach",
            "program": "<PATH_TO_SQUASHFS_ROOT>/squashfs-root/Logic",
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true,
                }
            ]
        }
    ],
    "version": "2.0.0"
}
5

Glad to hear that fixed it! Thanks! I don’t have the time now, but I’d like to get this into our SampleAnalyzer Readme. I picked gdb first since it’s the lowest common denominator for debugging on Linux, but I rarely reach for it directly outside simple core file analysis otherwise, in favor of VS Code.