Debugging C/C++ on the robot

See also

Overview | C++ | Python | .Net | Java | Matlab | Urbi

C++ SDK | C++ SDK Installation | C++ Tutorials | C++ Examples | C++ Tips and tricks | Debugging C/C++ on the robot


This section gives you some hints about debugging methods and gdb usage on the robot.

Note

A first approach when developing NAOqi modules is to build it as a remote module, using the debugger already installed on the host computer.

The second step is cross-compiling this module for the robot using the cross-toolchain.

Warning

The followings intends to provide help in case of cross-compilation.

However, the usage of gdb remains most of all the same.

For further information about gdb, please refer to the gdb manual: http://www.gnu.org/software/gdb/documentation/, or run help inside gdb.

Note

All the tools used for debugging are already installed on the robot or provided by the cross-toolchain.

Starting gdb

There are two ways of debugging some C/C++ binaries on your robot.

You can run the debugger either:

  • locally (i.e. only running gdb on the robot) or
  • remotely (i.e. running gdbserver on the robot and gdb on the host computer).

Note

Those debugging methods explained hereafter imply that the cross-compiled binaries have been sent on the robot before being run.

Warning

Cross-compiled binaries must be run on the robot.

Any attempt of execution on another system is a misunderstanding of the cross-compilation.

Such attempts will lead to:

  • in the best case: no execution at all;
  • in the worst case: an execution complaining about weird and incomprehensible warnings or errors.

Running debugger locally on the robot

Warning

Make sure you have built the module enabling the debug symbols (this is the default behavior when using the cross-toolchain).

On the robot, just run:

$ gdb naoqi-bin

Then, execute any gdb commands you want. For further details, see Using gdb.

Running debugger remotely

Warning

Currently, this is only available on Linux host.

Note

All the tools used for debugging are already installed on the robot or provided by the cross-toolchain.

Assuming the host computer, from which you are working, has 192.168.0.2 as IP address, and 192.168.0.10 is the one of the robot:

  1. On the robot:

    $ gdbserver 192.168.0.2:2345 naoqi-bin [args]
    

    2345 is the port number to use (this is just an example).

  2. On the host computer:

    $ ~/.local/share/qi/toolchains/*/*-ctc/cross/bin/i686-aldebaran-linux-gnu-gdb naoqi-bin
    (gdb) set solib-absolute-prefix /path/to/your/build-directory
    (gdb) target remote 192.168.0.10:2345
    

Then, execute any gdb commands you want in the debugger running on the host computer. For further details, see Using gdb.

Using gdb

The followings only give some basics about gdb.

For further information about gdb:

Managing breakpoints

(gdb) break <absolute path of the source file on the host computer>:<line number>

or

(gdb) break <absolute path of the source file on the host computer>:<function name>

Once created, a breakpoint id number is automatically associated.

You can then enable or disable any breakpoints by their id numbers:

(gdb) enable <breakpoint id>
(gdb) disable <breakpoint id>

Execution inside gdb

Start the program passing some arguments:

(gdb) run <arg1> <arg2>

For naoqi-bin, you might want to set a higher context level (refer to NAOqi man page or the qiLog API from libqi), to do so:

(gdb) run -d -c 7

To pause the execution, just press Ctrl-C, then press C to continue.

To quit gdb:

(gdb) quit

Exploiting breakpoints

Once the program has triggered a breakpoint, it execution is paused.

Then, you can:

  • Display the source code around the breakpoint (this requires the sources at the same location on the robot as they are on the host):

    (gdb) list
    
  • Display the backtrace:

    (gdb) bt
    
  • Move up and down in the backtrace:

    (gdb) up
    (gdb) down