Services - tools - models - for embedded software development
Embecosm divider strip
Prev  Next

Chapter 2.  Overview of GDB Internals

2.1. GDB Nomenclature
2.2. Main Functional Areas and Data Structures
2.2.1. Binary File Description (BFD)
2.2.2. Architecture Description
2.2.3. Target Operations
2.2.4. Adding Commands to GDB
2.3. GDB Architecture Specification
2.3.1. Looking up an Existing Architecture
2.3.2. Creating a New Architecture
2.3.3. Specifying the Hardware Data Representation
2.3.4. Specifying the Hardware Architecture and ABI
2.3.5. Specifying the Register Architecture
2.3.6. Specifying Frame Handling
2.4. Target Operations
2.4.1. Target Strata
2.4.2. Specifying a New Target
2.4.3. struct target_ops Functions and Variables Providing Information
2.4.4. struct target_ops Functions Controlling the Target Connection
2.4.5. struct target_ops Functions to Access Memory and Registers
2.4.6. struct target_ops Functions to Handle Breakpoints and Watchpoints
2.4.7. struct target_ops Functions to Control Execution
2.5. Adding Commands to GDB
2.6. Simulators
2.7. Remote Serial Protocol (RSP)
2.7.1. RSP Client Implementation
2.7.2. RSP Server Implementation
2.8. GDB File Organization
2.9. Testing GDB
2.10. Documentation
2.11. Example Procedure Flows in GDB
2.11.1. Initial Start Up
2.11.2. The GDB target Command
2.11.3. The GDB load Command
2.11.4. The GDB break Command
2.11.5. The GDB run Command
2.11.6. The GDB backtrace Command
2.11.7. The GDB continue Command after a Breakpoint
2.12. Summary: Steps to Port a New Architecture to GDB

There are three major areas to GDB:

  1. The user interface. How GDB communicates with the user.

  2. The symbol side. The analysis of object files, and the mapping of the information contained to the corresponding source files.

  3. The target side. Executing programs and analyzing their data.

GDB has a very simple view of a processor. It has a block of memory and a block of registers. Executing code contains its state in the registers and in memory. GDB maps that information to the source level program being debugged.

Porting a new architecture to GDB means providing a way to read executable files, a description of the ABI, a description of the physical architecture and operations to access the target being debugged.

Probably the most common use of GDB is to debug the architecture on which it is actually running. This is native debugging where the architecture of the host and target are the same.

For the OpenRISC 1000 GDB is normally run on a host separate to the target (typically a workstation) connecting to the OpenRISC 1000 target via JTAG, using the OpenRISC 1000 Remote JTAG Protocol. Remote debugging in this way is the most common method of working for embedded systems.

Embecosm divider strip
Prev   Next
1.4.  About Embecosm  Home 2.1.  GDB Nomenclature

Copyright © 2008 Embecosm Limited