UsingVSCode: Difference between revisions

From GNU Radio
Jump to navigation Jump to search
 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Source level debugging OOT C++ modules with Visual Studio Code =
= Source level debugging OOT C++ modules with Visual Studio Code =


The following instructions were created using VSCode v1.33.1 on Ubuntu 18.04
The following instructions were updated using VSCode v1.63.2 on Ubuntu 20.04


== Prerequisites ==
== Instructions ==


'''VSCode must be run as sudo to debug using GDB.  Haven't found a way around this yet.'''
 
1) In VSCode Extensions Marketplace, install the "C/C++" and "Python" extensions from Microsoft
 
2) Build the target OOT module and install into the pybombs prefix (or whatever other install method was used for GNU Radio)
 
* '''Be sure when building the OOT module, use -DCMAKE_BUILD_TYPE=Debug as one of the cmake flags''', e.g:


  <nowiki>
  <nowiki>
sudo code . --user-data-dir $TMPDIR</nowiki>
cmake ../ -DCMAKE_BUILD_TYPE=Debug</nowiki>
 
3) Create a flowgraph that calls your module


where $TMPDIR is a temporary location for VS Code to place its user data files. 
* In GRC, it is helpful to spool a temporary .py by changing the ID in options, generating the flowgraph, then changing the id back, so that direct changes to the python are not overwritten when the flowgraph is run from GRC


NOTE: Using . as the user-data-dir will litter the current directory with files and folder.


NOTE: The most recent versions of vscode do not require code to be run as sudo, so try without first
=== Launching from VsCode ===


== Instructions ==
The simplest way to achieve source level debugging is to launch the top level flowgraph (python file) from VsCode.


a) Set breakpoints in VSCode that you want to hit
* Like any other IDE with source level debugging, these can also be set while the code is free running


1) In VSCode Extensions Marketplace, install C++ and GDB Extensions (also Python Debugger for stepping through Python Code)
b) In VSCode, Click on the Debug Icon in the left panel (Triangle with a bug), and if one doesn't exist, "create launch.json file"
* Choose "C++ (GDB/LLDB)"
* This brings up launch.json and inserts some code


2) Build the target OOT module and install into the pybombs prefix (or whatever other install method was used for GNU Radio)
d) Modify the configuration so that the program to debug is python (either python2 or python3 depending gnuradio branch)
* The launch.json should look like this:
<nowiki>
{
    "version": "0.2.0",
    "configurations": [
       
        {
            "name": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "/usr/bin/python3",
            "args": ["-u","/path/to/flowgraph.py"],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ]
        },
    ]
}</nowiki>


* Be sure when building the OOT module, use -DCMAKE_BUILD_TYPE=Debug as one of the cmake flags, e.g:


<nowiki>
e) From the menu Debug:Start Debugging (F5) will start the python and land on your breakpoints!
cmake ../ -DCMAKE_BUILD_TYPE=Debug</nowiki>


3) Create a flowgraph that calls your module
=== Attaching to Process ===


* In GRC, it is helpful to spool a temporary .py by changing the ID in options, generating the flowgraph, then changing the id back, so that direct changes to the python are not overwritten when the flowgraph is run from GRC
Another alternative is to attach to already running process. This is useful for more complicated systems and flowgraphs


4) Add a sleep into the python file
a) (optional) Add a sleep into the python file


* Place after the import statement for your module
* Place after the import statement for your module
Line 41: Line 76:
import time; time.sleep(15)</nowiki>
import time; time.sleep(15)</nowiki>


5) Set breakpoints in VSCode that you want to hit
b) Set breakpoints in VSCode that you want to hit
* Like any other IDE with source level debugging, these can also be set while the code is free running
* Like any other IDE with source level debugging, these can also be set while the code is free running


6) In VSCode, Debug --> Open Configurations brings up a "Set Environment" selection
c) In VSCode, Debug --> Open Configurations brings up a "Set Environment" selection
* Choose GDB
* Choose GDB
* This brings up launch.json
* This brings up launch.json


7) Add Attach type of configuration
d) Add Attach type of configuration
* Debug --> Add Configuration
* Debug --> Add Configuration
* Select C/C++ (gdb) Attach
* Select C/C++ (gdb) Attach
* This inserts some code
* This inserts some code


8) Modify the configuration so that the program to debug is python (either python2 or python3 depending gnuradio branch)
e) Modify the configuration so that the program to debug is python (either python2 or python3 depending gnuradio branch)
* The launch.json should look like this:
* The launch.json should look like this:
  <nowiki>
  <nowiki>
Line 83: Line 118:




9) From a terminal, launch the python script which uses your module in a flowgraph
f) From a terminal, launch the python script which uses your module in a flowgraph


10) From VSCode, Start Debugging (F5), and you will be prompted to select the process to attach to
g) From VSCode, Start Debugging (F5), and you will be prompted to select the process to attach to


11) Start typing python, and then choose the python instance which is running your flowgraph
h) Start typing python, and then choose the python instance which is running your flowgraph


12) At this point (or after the script passes time.sleep) GDB should attach and breakpoints will be active
i) At this point (or after the script passes time.sleep) GDB should attach and breakpoints will be active

Latest revision as of 17:52, 20 December 2022

Source level debugging OOT C++ modules with Visual Studio Code

The following instructions were updated using VSCode v1.63.2 on Ubuntu 20.04

Instructions

1) In VSCode Extensions Marketplace, install the "C/C++" and "Python" extensions from Microsoft

2) Build the target OOT module and install into the pybombs prefix (or whatever other install method was used for GNU Radio)

  • Be sure when building the OOT module, use -DCMAKE_BUILD_TYPE=Debug as one of the cmake flags, e.g:
cmake ../ -DCMAKE_BUILD_TYPE=Debug

3) Create a flowgraph that calls your module

  • In GRC, it is helpful to spool a temporary .py by changing the ID in options, generating the flowgraph, then changing the id back, so that direct changes to the python are not overwritten when the flowgraph is run from GRC


Launching from VsCode

The simplest way to achieve source level debugging is to launch the top level flowgraph (python file) from VsCode.

a) Set breakpoints in VSCode that you want to hit

  • Like any other IDE with source level debugging, these can also be set while the code is free running

b) In VSCode, Click on the Debug Icon in the left panel (Triangle with a bug), and if one doesn't exist, "create launch.json file"

  • Choose "C++ (GDB/LLDB)"
  • This brings up launch.json and inserts some code

d) Modify the configuration so that the program to debug is python (either python2 or python3 depending gnuradio branch)

  • The launch.json should look like this:
{
    "version": "0.2.0",
    "configurations": [
        
        {
            "name": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "/usr/bin/python3",
            "args": ["-u","/path/to/flowgraph.py"],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ]
        },
    ]
}


e) From the menu Debug:Start Debugging (F5) will start the python and land on your breakpoints!

Attaching to Process

Another alternative is to attach to already running process. This is useful for more complicated systems and flowgraphs

a) (optional) Add a sleep into the python file

  • Place after the import statement for your module
  • If you are debugging the constructors of your module, then place the sleep before your import
import mymodule
import time; time.sleep(15)

b) Set breakpoints in VSCode that you want to hit

  • Like any other IDE with source level debugging, these can also be set while the code is free running

c) In VSCode, Debug --> Open Configurations brings up a "Set Environment" selection

  • Choose GDB
  • This brings up launch.json

d) Add Attach type of configuration

  • Debug --> Add Configuration
  • Select C/C++ (gdb) Attach
  • This inserts some code

e) Modify the configuration so that the program to debug is python (either python2 or python3 depending gnuradio branch)

  • The launch.json should look like this:
{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [

        { 
            "name": "(gdb) Attach",
            "type": "cppdbg",
            "request": "attach",
            "program": "/usr/bin/python3",
            "processId": "${command:pickProcess}",
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ]
        },

    ]
}


f) From a terminal, launch the python script which uses your module in a flowgraph

g) From VSCode, Start Debugging (F5), and you will be prompted to select the process to attach to

h) Start typing python, and then choose the python instance which is running your flowgraph

i) At this point (or after the script passes time.sleep) GDB should attach and breakpoints will be active