Debug plugins with VSCode

Hello, I would like to ask how to debug plugins within VSCode with gdb in a good way. I’m able to attach to a running instance of Rack and debug a plugin that was built with the SDK. Sadly, most interesting variables are hidden as <optimized out>.

So, I would like to build Rack from source (done) and build my plugins right in the plugins folder, as the Build guide points out.

Now I can run make debug and gdb is running my newly build instance of Rack. But any changes I’ve done to my plugin are not being build right now. Confusingly, the loaded patch is the same for my previously installed Rack or my own build.

So I guess I got something wrong on how this all is meant to work.

Secondly, I would like to use VSCode for debugging with gdb. How to set that all up? This is what I have done so far, but I’m very confused how this should be done, can you help me?

launch.jason:


    {
      "version": "0.2.0",
      "configurations": [
          {
              "name": "(gdb) Launch",
              "type": "cppdbg",
              "request": "launch",
              "program": "C:/Users/loren/Documents/dev/Rack/Rack.exe",
              "args": [],
              "stopAtEntry": false,
              "cwd": "${workspaceFolder}",
              "externalConsole": true,
              "MIMode": "gdb",
              "miDebuggerPath": "C:/msys64/mingw64/bin/gdb.exe",
            
              "setupCommands": [
                  {
                      "description": "Enable pretty-printing for gdb",
                      "text": "-enable-pretty-printing",
                      "ignoreFailures": true
                  }
              ],
              "preLaunchTask": "Build and debug"
          }
      ]
  }
task.jason:

  {
        "version": "2.0.0",
        "tasks": [
          {
              "label": "Build and debug",
              "type": "shell",
              "command": "make debug",
              "options": {
                  "cwd": "${workspaceFolder}",
                  "env": {
                      "PATH": "C:\\msys64\\usr\\bin\\;C:\\msys64\\mingw64\\bin"
                  }
              },
              "problemMatcher": {
                  "owner": "cpp",
                  "fileLocation": [
                      "absolute"
                  ],
                  "pattern": {
                      "regexp": "^(.*):(\\d+):(\\d+):\\s+(warning|error):\\s+(.*)$",
                      "file": 1,
                      "line": 2,
                      "column": 3,
                      "severity": 4,
                      "message": 5
                  }
              }
          }
    ]
    }

Can anyone point me in the direction to figure this all out? Thanks a lot!

You need to run Rack with -d to tell it to pick up the plugins in the plugins folder rather than the usual system folder. To do that, use the args property in launch.json:

"args": ["-d"],

You can build without optimisation by removing -O3 from this line in compile.mk:

FLAGS += -O3 -funsafe-math-optimizations -fno-omit-frame-pointer

which should fix the <optimized out> problem.

I’d also recommend commenting out all the strip commands in Makefile.

1 Like

Ok, nice. If I delete that -O3 from compile.mk, after make clean and make I get errors in the building process, do I have to rebuild the dependencies as well?

How do I perform a build on the plugin itself?

Thanks!

Ah, sorry, if you turn optimisation off then you also need to make this change in dep/oui-blendish/blendish.c:

-    #define BND_INLINE inline
+    #define BND_INLINE static

How do I perform a build on the plugin itself?

Just run make in plugins/myplugin. There’s no need for any installation step if you then run Rack with -d.

Just a quick technical note, in case you’re not aware.

For debugging you must use the debug version of Rack, as you mentioned you’ve built from source that’s step 1.

Step 2, use the debug version of the plugin for testing, this is the version in the root folder of your local repo NOT the version in the dist folder.

HTH.

Do you need to do this if using GCC?

Allrigth, thanks. Just to be sure Ii got that right: With make in my Rack repository I do build a debug version of rack? Because make debug only calles gdb. Am I right?

Steve: Without that change to oui-blendish, it won’t build without optimisation. (I’m not aware of any way to build Rack with anything other than gcc - am I missing something?)

Lorenz: Yes, you’re building a debug version of Rack when you run make. The command make debug doesn’t actually make anything; it just runs the debugger.

1 Like

Thanks that helped to build Rack again. I commended out all lines containing Strip in the Makefile in my Rack folder.

Sadly, breakpoints I add in VSCode do not trigger.

Do your breakpoints work if you set them before running Rack? The reason I ask is that when you add a breakpoint while the process is running, you may have to break into the process by pressing F12 (maybe twice) while Rack has the focus, and then continuing the process, before the new breakpoints take effect.

Yes, I have set the breakpoint before I start the debugging with VSCodes “Debug C/C++ file”

Another strange thing to add:

I start my debug session by hitting that “Debug C/C++ File” button in the top right corner of VSCode. Then I select my task (it’s called “(gdb) Launch”, according to my launch.json file)

I get:

Executing task: make debug 

gdb --args ./Rack.exe -d
GNU gdb (GDB) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./Rack.exe...

I have to type “run” to start Rack, breakpoints do not trigger, Vscode does not react to the debugging session. I can hit F12 with Rack in focus, then it stops, but no reaction from VSCode

When I then close Rack and quit gdb, another instance of rack is loaded and now the debugger of VSCode is reacting, breakpoint trigger and I can set new breakpoints and “activate” them with F12.

But still most variables are hidden in <optimized out>

I’m very thankful for your support! It’s amazing how fast and precise your support is!

You need to remove the preLaunchTask entry from launch.json.

What you have in task.jason is a task that will launch the command-line debugger, not the VS Code debugger. What you have in launch.json will launch the VS Code debugger. But that preLaunchTask entry says “Go and run the command-line debugger before running the VS Code debugger.”

Once that’s removed, you should be good to go!

1 Like

Haha, I got it. My fault :confused:

I updatet the RACK_DIR variable to point to my build of Rack, but I didn’t restarted my MINGW64 shell, so the plugin was still built based on the SDK.

Thanks a lot to everyone. For the next one who has trouble debugging, here is quick guide:

  1. build Racks dependencies from source
  2. Remove -O3 from this line in compile.mk:
FLAGS += -O3 -funsafe-math-optimizations -fno-omit-frame-pointer
  1. change in dep/oui-blendish/blendish.c:
-    #define BND_INLINE inline
+    #define BND_INLINE static
  1. build Rack with make
  2. prepare launch.json and task.json, don’t forget to add "args": ["-d"], to launch.json
  3. be sure to have your RACK_DIR variable pointing to your build of Rack
  4. build your plugin with make in /plugin/your_plugin
  5. start to debug in VSCode, select your prepared task
1 Like

Oh yes, that works. Thank you!

Great! I’m glad you’re up and running, and thanks for posting a summary of how you got it working. :slight_smile: