GDB

GDB stands for GNU Debugger, which is a command-line debugger that is available on many systems. GDB is free software released under the GNU General Public License.

History

GDB was modeled after the DBX debugger, which came with Berkeley Unix distributions. The initial GDB was written by Richard Stallman in 1986. Currently, it is maintained by the GDB Steering Committee, which is appointed by the Free Software Foundation.

Remote operation

When debugging an Embedded System with GDB, remote mode is used. Remote operation means that GDB runs on one machine and the program being debugged runs on another.

In this situation, GDB is the client, and it communicates with a remote "stub." The GDB protocol can use a serial link (UART) or TCP/IP. Modern systems almost always use TCP/IP. Typically, the remote stub is a debug probe (such as J-Link), and it uses a GDB server and communicates with GDB via TCP/IP.

GDB Protocol

The GDB Protocol has evolved over the years. It is used by GDB, but has now been adopted as a more or less standardized way for debuggers to communicate with debug probes via TCP/IP.

In this scenario, the debugger is acting as a client, connecting to the debug probe, which acts as a server. In most cases, the client (debugger) and the server run on the same machine, so the client connects to a port on the local host.

Advantages

• Process separation
  One of the advantages of this approach is that the debugger and the debug-probe software run in different processes, so that they are shielded from one another. This is quite helpful, especially if they are maintained by different software developers, teams, or companies. Should the debug-probe software crash, the other debugger/IDE is not affected (and vice versa).
• Interoperability
• Debugging removal

LMA and VMA

GDB uses the following address information provided by an ELF file:

• Virtual memory address (VMA):
  The address the code is executed from/linked to.
• Load/local memory address (LMA):
  The address that the code is programmed to by the debugger/programmer.

Both addresses may differ from one another. It is the loader's responsibility to make sure that the section is accessible via the VMA.
An example for VMA != LMA:

• The image is loaded to QSPI flash (LMA).
• On boot, the application is copied to SDRAM (VMA) by the startup code and bootloader from where it is executed.

Adjusting the LMA

In some cases, the user might want to adjust the LMA. GDB's load command allows definition of an offset for this purpose:

load [FILE] [OFFSET]

Example

During development of an application, a bootloader is to be simulated/skipped.

• The bootloader is responsible for copying the R/O code/data to the VMA.
• The startup code is responsible for copying the R/W data sections/initialization image.
• LMA 0x10000000 - 0x1000FFFF (QSPI Flash).
• VMA 0x20000000 - 0x2000FFFF (SDRAM).

To skip the bootloader, the image has to be loaded twice:

• Once to the LMA, to make sure that the startup image and R/W code will be copied to VMA.
• Once to the VMA, to simulate the copy process of the other sections by the BTL.

Here, the GDB load command can be used:

load xxx.elf            // Load to LMA (0x10000000) => startup code
load xxx.elf 0x10000000 // Load to LMA + <Off> (0x10000000 + 0x10000000 = 0x20000000) => simulate BTL