Copyright (C) 2024, Axis Communications AB, Lund, Sweden. All Rights Reserved.
This guide will walk you through the process of debugging an ACAP application running on an Axis device using GDB and Visual Studio Code.
The files for building the application and the debug tools are organized in the following structure.
remote-debug-example
├── .gitignore
├── app
│ ├── .devcontainer
│ │ ├── aarch64-container
│ │ │ └── devcontainer.json
│ │ └── armv7hf-container
│ │ └── devcontainer.json
│ ├── .vscode
│ │ └── launch.json
│ ├── LICENSE
│ ├── Makefile
│ ├── manifest.json
│ └── remote_debug.c
├── Dockerfile
└── README.md- .gitignore - gitignore file for the specific example, to avoid any build files being accidentally committed.
- app/.devcontainer/aarch64-container/devcontainer.json - Configuration file for the aarch64 development container.
- app/.devcontainer/armv7hf-container/devcontainer.json - Configuration file for the armv7hf development container.
- app/.vscode/launch.json - Configuration file for the Visual Studio Code debugger.
- app/LICENSE - Text file which lists all open source licensed source code distributed with the application.
- app/Makefile - Build and link instructions for the application.with debug options added.
- app/manifest.json - Defines the application and its configuration.
- app/remote_debug.c - Application demonstrating a simple debugging scenario.
- Dockerfile - Assembles an image containing the ACAP Native SDK and builds the application using it.
- README.md - Step by step instructions on how to run the example.
- Project structure
- The setup
- Prerequisites
- Build and start a dev container
- Build and install ACAP application
- Upload and start gdbserver
- Start debugging in dev container
- Cleanup
- Troubleshooting
- License
- Axis device (also referred to as device or target in this guide)
- Will run
gdbserverand attach to an installed ACAP application to debug.
- Will run
- User machine (also referred to as desktop in this guide)
- Use Visual Studio Code to run
gdb-multiarchand connect to thegdbserveron the device. - Needs access to the application binary with debug symbols (not stripped).
- Debugging is done in a dev container (also referred to as development container and the extension is called Dev Container) in Visual Studio Code.
- Use Visual Studio Code to run
- Visual Studio Code installed on desktop.
- Developer Mode enabled in the target device.
- Install Visual Studio Code extensions
- Dev Containers (ms-vscode-remote.remote-containers)
A dev container can be attached to Visual Studio Code and simplifies the debugging process.
Open a terminal, move to the example directory and run one or both of the following commands to build the dev container for the architecture of your Axis device:
docker build . --platform=linux/amd64 --build-arg ARCH=armv7hf -t dev_container:armv7hf
docker build . --platform=linux/amd64 --build-arg ARCH=aarch64 -t dev_container:aarch64The dev container includes the gdbserver binary for remote debugging.
- Start Visual Studio Code and run
Dev Containers: Open Folder in Container...via the Command Palette available by pressingF1orCtrl+Shift+P. - Browse to the
appfolder in the repository and chooseOpen. - In the dev container, make sure to install the recommended Visual Studio Code
extensions (not the one stated in prerequisites), usually a dialog
prompts the user to install recommended extensions shortly after the
dev container is started. See field
extensionsin filesapp/.devcontainer/<ARCH>-container/devcontainer.jsonfor more information. - Depending on the architecture of the device you like to debug, choose the architecture of the dev container when prompted.
- If you don't have a terminal open by default in Visual Studio Code, open one
via the
Terminal → New Terminalmenu. - The terminal will open inside the dev container in the
/opt/appdirectory and is now ready for development.
This part shows how to build and install the ACAP application of the example in the dev container started in previous section.
To build the ACAP application, run the following command from the same terminal:
acap-build .The /opt/app directory now contains build artifacts, where the ACAP application
is found with suffix .eap and depending on which SDK architecture that was
chosen, one of these files should be found:
remote_debug_1_0_0_aarch64.eapremote_debug_1_0_0_armv7hf.eap
Note
When developing interactively in a dev container, the build files will end up
in the source code directory of the repository, here called app. It's
recommended to use a .gitignore file to not commit build files in a
production repository. An example can be seen in the
.gitignore file of this repository.
To install the ACAP application on your device, make sure to enable the
Allow unsigned apps toggle through the web interface and run the following
command from the same terminal:
eap-install.sh <AXIS_DEVICE_IP> <ADMIN_ACCOUNT> <PASSWORD> installBefore uploading the gdbserver to your device, ensure that Developer
Mode is enabled. Developer Mode grants SSH access to
the ACAP application's dynamic user on the Axis device.
When the ACAP application has been uploaded to your device,
provided Developer Mode is enabled, an ACAP application user named
acap-remote_debug with SSH access should have been created.
Make sure to set the password for the application user before continuing to next section.
-
Open a new terminal in Visual Studio Code, using either
Terminal → New TerminalorTerminal → Split Terminal. This terminal will also be running inside the dev container, just like the existing terminal. Using a second terminal allows for better visualization and keeps the debugging process within the IDE. -
In the new terminal, upload the
gdbserverbinary to the Axis device directory/tmpby usingscp:scp /opt/build/gdb/bin/gdbserver acap-remote_debug@<AXIS_DEVICE_IP>:/tmp/
In the same terminal (used for scp in previous section), log into the device
with ssh, start the gdbserver with the application binary, and open a TCP
connection to a debug port on the Axis device, here port 1234:
ssh acap-remote_debug@<AXIS_DEVICE_IP>
/tmp/gdbserver :1234 /usr/local/packages/remote_debug/remote_debugNote
If your manifest.json file contains runtime options under
acapPackageConf.setup.runOptions, these are not automatically propagated to
the gdbserver. You must explicity include them when starting the gdbserver.
For example, if your manifest.json contains:
"runOptions": "--arg1 value1 --arg2 value2"Start the gdbserver with:
/tmp/gdbserver :1234 /usr/local/packages/remote_debug/remote_debug --arg1 value1 --arg2 value2You should see output similar to:
Process /usr/local/packages/remote_debug/remote_debug created; pid = 7423
Listening on port 1234Tip
Keep both terminals open during the debugging process: one for building and installing the application, and one for the SSH connection to the device.
Note
The launch.json file contains a hardcoded IP address (192.168.0.90) for
the Axis device. This usually works if the target device is connected directly
to the computer, as it will typically have this IP address. However, if you
are debugging a device with a different IP address, make sure to update the
miDebuggerServerAddress field in launch.json with the correct IP address
and port number.
-
In the dev container, open
remote_debug.cand pressF5to start debugging. -
You can now set breakpoints, step through the code, and inspect variables using Visual Studio Code's debugging features.
-
In the SSH session, you should see output similar to:
Remote debugging from host ::ffff:192.1.2.3, port 1234
To rebuild and reinstall the ACAP application after making changes, run the following commands in the dev container terminal:
make clean
acap-build .
eap-install.sh <AXIS_DEVICE_IP> <ADMIN_ACCOUNT> <PASSWORD> installNote
If this simple example is fixed, it will run once and exit, which will also
exit the gdbserver running on the Axis device. To run a new remote
debug the gdbserver needs to be restarted.
To remove the built files and stop the debugging session:
-
Press
Shift+F5in Visual Studio Code to stop debugging. -
In the dev container terminal, run the following command to remove the built files:
make clean
- If SSH access is not working after enabling
Developer Mode, try restarting the device and then reinstall the ACAP application. - If SSH access is not working after upgrading the ACAP application, make sure to set the SSH password for the ACAP application user again.
- If you encounter permission issues when uploading the
gdbserveror starting the debugging session, make sure that the ACAP application user has SSH access enabled and a password set. - If the debugging session doesn't start, verify that the
gdbserveris running on the device and listening on the correct port. - If you see an error message about missing debug symbols, make sure that the ACAP application was built with debug symbols and that the correct binary is being used for debugging.