Difference between revisions of "GDB"

From SEGGER Wiki
Jump to: navigation, search
m
(LMA and VMA)
 
(9 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
[[Category:Knowledge Base]]
 
[[Category:Knowledge Base]]
  +
[[Category:GDB related]]
GDB stands for GNU Debugger.
 
GDB is a command line debugger available on many systems.
+
GDB stands for GNU Debugger. It is a command line debugger available on many systems.
 
GDB is free software released under the GNU General Public License (GPL).
 
GDB is free software released under the GNU General Public License (GPL).
  +
  +
__TOC__
   
 
==History==
 
==History==
Line 17: Line 19:
 
=== GDB Protocol ===
 
=== GDB Protocol ===
 
The GDB Protocol has evolved over the years.
 
The GDB Protocol has evolved over the years.
It is used by GDB, but has no been adopted as a somewhat standardized way for debuggers to communicate to debug probes via TCP/IP.
+
It is used by GDB, but has now been adopted as a somewhat standardized way for debuggers to communicate to debug probes via TCP/IP.
 
In this scenario, the debugger is acting as client, connecting to the debug probe, acting as server.
 
In this scenario, the debugger is acting as client, connecting to the debug probe, acting as server.
 
In most cases, the client (debugger) and the server run on the same machine, so the client connects to a port on localhost.
 
In most cases, the client (debugger) and the server run on the same machine, so the client connects to a port on localhost.
 
==== Advantages ====
 
==== Advantages ====
  +
* Process separation<br>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 or different teams or different companies. Should the debug probe software crash, it does not affect the other debugger / IDE and vice versa.
* 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 or different teams or different companies. Should the debug probe software crash, it does not affect the other debugger / IDE and vice versa.
 
 
* Interoperability
 
* Interoperability
 
* Remove debugging
 
* Remove debugging
  +
====Capabilities====
 
  +
== LMA and VMA ==
  +
GDB uses address information provided by the ELF file:
  +
* '''Virtual memory address''' (VMA):<br>Address, the code is executed from / linked to.
  +
* Load/'''Local memory address''' (LMA):<br>Address, the code is programmed to by debugger / programmer.
  +
Both addresses may differ from one another. It is the loaders responsibility to make sure that the section is accessible via the VMA.<br>An example for VMA != LMA would be:
  +
* The image is loaded to QSPI flash (LMA).
  +
* On boot, the Application is copied to SDRAM (VMA) by startup code & BTL from where it is executed.
  +
  +
=== Adjusting the LMA ===
  +
In some cases, the user might want to adjust the LMA.
  +
GDB's '''<tt>load</tt>''' command allows to define an offset for this purpose:<br>
  +
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:
  +
* To the LMA, to make sure that the startup image & R/W code will be copied to VMA.
  +
* To the VMA, to simulate the copy process of the other sections by the BTL.
  +
For this the GDB '''<tt>load</tt>''' 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

Latest revision as of 11:20, 25 October 2023

GDB stands for GNU Debugger. It is a command line debugger available on many systems. GDB is free software released under the GNU General Public License (GPL).

History

GDB was modeled after the DBX debugger, which came with Berkeley Unix distributions. The initial GDB was written by Richard Stallman, who started in 1986. Now 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, the remote mode is used. Remote operation is when GDB runs on one machine and the program being debugged runs on another.
In this situation, GDB is the Client, talking to 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, using a GDB-Server, and communicating 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 somewhat standardized way for debuggers to communicate to debug probes via TCP/IP. In this scenario, the debugger is acting as client, connecting to the debug probe, acting as server. In most cases, the client (debugger) and the server run on the same machine, so the client connects to a port on localhost.

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 or different teams or different companies. Should the debug probe software crash, it does not affect the other debugger / IDE and vice versa.
  • Interoperability
  • Remove debugging

LMA and VMA

GDB uses address information provided by the ELF file:

  • Virtual memory address (VMA):
    Address, the code is executed from / linked to.
  • Load/Local memory address (LMA):
    Address, the code is programmed to by debugger / programmer.

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

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

Adjusting the LMA

In some cases, the user might want to adjust the LMA. GDB's load command allows to define 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:

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

For this 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