Debugging Open Source Projects with VS Code and QNX Toolkit

Setting up a debugging environment in VS Code for such projects is not very difficult.

Let’s start by creating a folder. Name it, for example, qnx_workspace.

Open-source ports maintained by QNX are hosted on GitHub. One of the repositories contains a collection of build files for all available ports: https://github.com/qnx-ports/build-files

These build files are based on QNX recursive makefiles and support out-of-source builds.

Navigate to the qnx_workspace folder and clone the build-files repository, along with the source code repositories for the projects you would like to debug (for example: https://github.com/qnx-ports/dlt-daemon).

Start VS Code and open the qnx_workspace folder.

To make the debugging environment persistent, you can save the current workspace via File → Save Workspace As....
Later, you can restore it using File → Open Workspace from File....

Next, right-click the qnx_workspace folder and select QNX → Generate .vscode Files... from the context menu.
You will be prompted to select a project template - choose Other - configure the build on your own.

Now we need to tell VS Code how to build and debug the project:

.vscode/tasks.json contains tasks such as building or cleaning the project

.vscode/launch.json contains launch configurations

Example:
Debugging a test from the dlt-daemon project

The content of tasks.json:

{
    "version": "2.0.0",
    "tasks": [
        {
            "type": "shell",
            "label": "QNX: dlt-daemon build and install",
            "command": "CMAKE_BUILD_TYPE=Debug BUILD_TESTING=ON make -C build-files/ports/dlt-daemon install",
            "options": {
                "cwd": "${workspaceFolder}",
                "env": {
                    "QNX_HOST": "${env:QNX_HOST}",
                    "QNX_TARGET": "${env:QNX_TARGET}",
                    "MAKEFLAGS": "${env:MAKEFLAGS}",
                    "PATH": "${env:PATH}"
                }
            },
            "problemMatcher": [
                "$gcc"
            ],
            "group": {
                "kind": "build",
                "isDefault": true
            }
        },
    ]
}

Comments:

You can define multiple tasks in tasks.json (for example, build commands for multiple projects).
The "command" field specifies what will be executed when you run a task.

Refer to the corresponding README file in the build-files repository to find the appropriate build command:
https://github.com/qnx-ports/build-files/blob/main/ports/dlt-daemon/README.md

In this example, we build a debug configuration and install the project.

Some project build commands use the $(pwd) expression. Replace it with ${workspaceFolder}.

The content of launch.json:

{
  "version": "2.0.0",
  "configurations": [
    {
      "type": "qnx-gdb",
      "request": "launch",
      "name": "QNX: gtest_dlt_user on RPI",
      "gdb": "gdb",
      "program": "${workspaceFolder}/build-files/ports/dlt-daemon/nto-aarch64-le/build/tests/gtest_dlt_user",
      "args": ["--gtest_filter=t_dlt_user_shutdown_while_init_is_running.normal"],
      "remotePath": "",
      "qnxtarget": "default",
      "upload": true,
      "stopAtEntry": true,
      "preLaunchTask": "",
      "additionalSOLibSearchPath": "${env:QNX_TARGET}/aarch64le/usr/local/lib/"
    },
  ]
}

Comments:

You can define multiple launch configurations in launch.json.

The "program" field specifies the binary you want to execute on the target. In the example above, it is a Google Test program with multiple test suites.

The "args" field is optional and allows you to pass arguments to the program. In this case, we specify that only a single test case should be executed.

The "additionalSOLibSearchPath" field defines the paths where the QNX Toolkit searches for additional shared libraries required by the program. In our case, the DLT and Google Test libraries are located in usr/local/lib/ rather than usr/lib/, so we need to include this path. (The installation step in the build command copies all required libraries and related files to the SDP location.)

To debug your application, click the "Run And Debug" icon in the Primary Side Bar to open the corresponding view. Then, select your launch configuration from the dropdown list and press F5.

Note:

You can find more information in the following eCourse: Developing with the QNX Toolkit for VS Code

The instructions apply to a cross-compilation environment. However, you can use the QNX Developer Desktop (QDD) as the target, provided that the same SDP version was used to build the QDD target image as the SDP installed on your host.

A simple way to verify this is to compare the libc versions.

On the host:

use -i ${QNX_TARGET}/aarch64le/lib/libc.so.6

On the target:

use -i /proc/boot/libc.so.6

A typical output may look like this:

[qnxuser@qnxpi ~]$ use -i /proc/boot/libc.so.6
QNX_BUILDID=(GNU)c18638b19f9510e2890da0463d3d8482
NAME=libc.so.6
DESCRIPTION=C runtime library
DATE=2025/07/30-18:28:28-EDT
STATE=lookup
HOST=docker-n5
USER=builder
VERSION=8.0.0
TAGID=QNXOS_803-600
PACKAGE=com.qnx.qnx800.target.microkernel.core/2.2.0.00600T202507302003L

If the versions match, there is a good chance that the target is compatible with the SDP on your host. This check is required when using a prebuilt image (QSTI), but it can be skipped when building the image locally (CTI). The CTI build process downloads the SDP used for image generation, allowing you to use the exact same SDP for compiling your project and configuring the QNX Toolkit for VS Code.

If you want to debug projects directly in QDD, you can use either gdb or the Geany IDE that comes with QDD. See:

Write a Hello World application in C: https://www.qnx.com/developers/docs/qnxeverywhere/com.qnx.doc.qdd/topic/hello_world_c.html