Debugging Linux Software

This article describes how to debug user-space applications on the Linux on ARC.

Building Tool chain

Refer to README.md file in the toolchain repository to learn how to build toolchain for Linux uClibc toolchain. In most cases you would want:

$ ./build-all.sh --no-elf32

Toolchain will be installed to the ../INSTALL directory then.

Running Linux

There are two ways supported by Synopsys to run Linux on ARC cores: on the SystemC model based on nSIM simulator and on the AXS101 SDP.

SystemC Model

Source code of the SystemC model is supplied as an example with the nSIM distribution.

First you need to build model. Refer to this page for details .

By default model already contains a prebuilt Linux image that can be used to run and debug target applications. If you wish to have your own Linux image, then refer to this article for details: <How-to-build-Linux-kernel-with-GNU-4.8-tools>. If you are using Buildroot make sure that gdbserver is selected in the Target packages / Debugging, profiling and benchmarking.

AXS101 SDP

Section to be written.

Additional Configuration

To ease process of delivering target application into the ARC Linux it is recommended to configure NFS share and mount it on the ARC Linux. Refer to this article for details: <Configuring-NAT-for-the-Linux-Virtual-Platform#configure-nfs>.

Debugging Applications

It is assumed that one or another way you've copied target application to the target system. Run application on target with gdbserver:

# gdbserver :49101 <application-to-debug> [application arguments]

TCP port number could any port, not occupied by other applications. Then run GDB on the host:

$ arc-linux-gdb <application-to-debug>

Set path to the sysroot directory. Sysroot is a "mirror" of the target system file system: it contains copies of the applications and shared libraries installed on the target system. Sysroot directory should be set to allow GDB to step into shared libraries functions. Note that shared libraries and applications on the target system can be stripped from the debug symbols to preserve disk space, while files in the sysroot shouldn't be stripped. In case of Buildroot-generated rootfs sysroot directory can be found under <BUILDROOT_OUTPUT>/staging.

(gdb) set sysroot <SYSROOT_PATH>

Then connect to the remote gdbserver:

(gdb) target remote <TARGET_IP>:49101

You can find <TARGET_IP> via running ifconfig on the target system. TCP port must much the one used when starting up gdbserver. It is important that sysroot should be set before connecting to remote target, otherwise GDB might have issues with stepping into shared libraries functions.

Then you can your debug session as usual. In simplest case:

(gdb) continue

Debugging Applications with Native GDB

Starting from ARC GNU Toolchain release 2014.08 it is possible to build full GDB to run natively on ARC Linux. You can either select GDB in the Target applications of the Buildroot configuration, or build it as a usual cross-compiled application with using ./configure --host=arc-linux-uclibc.

Then you can debug applications the same way you do this on the host system without gdbserver.

When choosing between gdbserver and native GDB please consider pros and cons of native GDB.

Pros:

• Overhead for network communication between GDB and gdbserver is removed, theoretically improving debugging performance.
• Some features are not implemented in the gdbserver. One example is "follow-child" model of "follow-fork" behaviour.
• There is no need for a second host to perform debugging session, since everything is on the target system.

Cons:

• It is required that applications on target system should have debugging symbols (unless you are so hardcore that you don't need them). Debugging symbols, especially in the most verbose case occupy significant disk space. Depending on the type of target HW this might be or might not be a thing to consider. It is usually less of a problem on development systems and even more so simulators, however disk space is probably very limited on the production systems.
• Not only debugging symbols will take noticeable disk space, but also GDB will also read them intensively, so if target file system has a very poor performance, this might be noticeable.
• Support for native GDB has been added much later to the ARC tool chain, hence it is theoretically less stable.
• Host GDB requires more computational power than gdbserver. This might offset all of the gains from exclusion of networking layer.

In general it is highly dependent on the target system whether gdbserver or native GDB is better and it is up to the software developer to decide what is better in their particular case.