Preparing Yocto Development Environment for Debugging: Difference between revisions

Strace is mostly used for problems outside of the binary itself; for example configuration files, input data, and kernel interfaces. This recipe will explain how to use it. For setting up the environment to use it, remember that the package "tools-debug" already includes it, so you should add to your local.conf file:

<syntaxhighlight lang=make>

EXTRA_IMAGE_FEATURES += "tools-debug"  

If you want to only add strace, make sure the following are added to your image recipe file:

<syntaxhighlight lang=make>

IMAGE_INSTALL += "strace procps"

Profiling and tracing can be achieved using Perf. The basic setup can be done manually, or you can also use the available at the git repository from the Yocto Project. The following options are the minimum needed for running perf.  

<syntaxhighlight lang=make>

EXTRA_IMAGE_FEATURES = "debug-tweaks tools-profile dbg-pkgs"

PACKAGE_DEBUG_SPLIT_STYLE = 'debug-file-directory'

</syntaxhighlight>

=== Valgrind ===

As you would do for any other package that you want to include in your image and is not part of the default configuration, you need to add the recipe to build it. The source will depend on what board you a using, and you must add the recipe to your meta-layer. Valgrind also needs some of the previously defined features on your '''local.conf''', specifically:   

<syntaxhighlight lang=make>

EXTRA_IMAGE_FEATURES += " dbg-pkgs tools-debug "

</syntaxhighlight>

Also, remember to add it to your image recipe, as follows:

<syntaxhighlight lang=make>

IMAGE_INSTALL += "valgrind"

=== Tcpdump ===

Tcpdump is a powerful command-line packet analyzer; and libpcap, a portable C/C++ library for network traffic capture. You can add it to your target image by including the corresponding recipe on your meta-layer. To add it to your image, you need to add to your image recipe:

<syntaxhighlight lang=make>

IMAGE_INSTALL += "tcpdump"

=== Kdump ===

Kdump uses kexec to quickly boot to a dump-capture kernel whenever a dump of the system kernel's memory needs to be taken (for example, when the system panics). The system kernel's memory image is preserved across the reboot and is accessible to the dump-capture kernel. You can find more information on how to use it in the [[https://devtalk.nvidia.com/default/topic/1020708/jetson-tx2/method-to-modify-use-different-device-tree-in-r28-1/ Yocto Project repository]] For Yocto, it is available in the kexec-tools package, and it can be included in your image by adding the recipe to your meta-layer, and modifying your recipe by adding the line:   

<syntaxhighlight lang=make>

IMAGE_INSTALL += "kexec-tools"

As previously mentioned, GDB is included in the package "tools-debug", so commonly the EXTRA_IMAGE_FEATURES would be set as follows:

<syntaxhighlight lang=make>

EXTRA_IMAGE_FEATURES = "tools-debug debug-tweaks dbg-pkgs"

Notice also that the package "dbg-pkgs" will help us include the debug symbols for all the packages. To enable debugging symbols for a specific package, the -dbg package must be included. This can be done by modifying the recipe, or the local.conf file, by adding the following line:

<syntaxhighlight lang=make>

IMAGE_INSTALL += " $PACKAGE_NAME $PACKAGE_NAME-dbg"

==== Setting up environment for remote debugging (GDBServer) ====

The host GDB must have access to all debugging information and unstripped binaries, libraries and target must be compiled with no optimizations, all of which were mentioned on the general environment setup. For more information, refer to the official documentation. The steps are listed here for convenience:

<syntaxhighlight lang=make>

IMAGE_GEN_DEBUGFS = "1"

* Configure the system to include gdbserver in the target filesystem by adding gdbserver to either the local.conf or the recipe:

<syntaxhighlight lang=make>

IMAGE_INSTALL += “gdbserver"

* Construct the image and companion filesystem

<syntaxhighlight lang=bash>

</syntaxhighlight>

                        

* Build the cross GDB component and make it available for debugging. Build the SDK that matches the image. Building the SDK is best for a production build that can be used later for debugging, especially during long term maintenance:

<syntaxhighlight lang=make>

</syntaxhighlight>