sw-debug-gdb (libgdb.la :: gdb_component_library)


The gdb component is an implementation of the GDB stub.



The gdb component communicates with other components through its pins, and also through four relations: a cpu uni-relation, a gloss uni-relation, a target-schedulers multi-relation and a host-schedulers multi-relation.

Note that in sid, "turning the target power on or off" means that the gdb component drives its yield pin, sets the target schedulers' enabled? attributes through the target-schedulers relation and sets the host schedulers' yield-host-time? attributes through the host-schedulers relation. See sid-sched for an explanation of these pins.


When init is driven, target power is turned off. Basically, this means the target will wait for further input from gdb.


When the gdb component wants the target system to yield, it drives the yield pin. Likewise, it will drive the restart pin to restart the target system. The restart pin is typically connected to a hw-reset hw-glue-sequence component that has connections to any of the target components that need to be reset.

When the start-target pin is driven, the target power will be turned on. The start-target pin should be driven by a sid-side component that wants the target cpu to start again. Use this pin with caution; driving it could upset an attached external debugger.

The stop-target pin should be driven from a sid-side component that wants to stop the target cpu. This pin will be ignored if there are signals pending.

When gdb itself or the gdb component (see the explanation of the enable-Z-packet? attribute) sets a software breakpoint, it puts the cpu's instruction cache out of sync with the actual contents of memory. So the gdb component will drive the flush-icache pin when it wants the cpu to invalidate its instruction cache.

As long as gdb is connected to the gdb component, the connected? attribute will be true.

system call emulation

When gdb detaches from the gdb component, the component drives the process-signal pin.

The gloss-process-signal pin is typically driven by a gloss component. It tells the gdb component that the gloss component has processed an exit system call.

The gdb component's trap pin is usually connected to the gloss component's trap-code-chain pin. The gloss component sends any trap code that it cannot handle down the trap code chain (via the trap-code-chain pin), and any debugging-related trap will be handled by the gdb component. If the gdb component knows how to handle the trap code, it will handle it and then drive the trap pin with the cpu_trap_handled value. See sw-gloss-arm_angel and hw-cpu-arm7t for more information on trap and trap-code pins.

pin i/o

The remote-rx and remote-tx pins are the pins that the gdb component uses to receive data from and transmit data to gdb. They are typically connected to a sid-io-socket's rx and tx pins respectively. gdb connects to this sid-io-socket component via TCP, and can then be used just as if it were debugging a normal remote target.

The target-tx pin is used to transmit characters coming from the target's standard out back to gdb. These characters are transmitted using an "O" packet.


When the deinit pin is driven, the gdb component disconnects from gdb.


When set to true, the trace-gdbsid? and trace-gdbserv? attributes turn on trace messages for the gdb component member functions and the stub functions respectively. Trace messages are printed to stderr.

When the exit-on-detach? attribute is true, the gdb component drives its process-signal pin when gdb detaches from the target.

When the enable-E-packet? attribute is true, the gdb component recognizes e packets that it receives from gdb, and performs efficient step-out-of-range operations. Without this, gdb often maps users' "step" operations to a sequence of instruction-granularity steps, multiplying the amount of traffic (and time) required. Some versions of gdb require running the

set remote E-packet on
command in order to activate this feature.

When the enable-Z-packet? attribute is true, the gdb component recognizes Z packets that it receives from gdb, and sets breakpoints according to their contents. If the enable-Z-packet? attribute is false, then gdb sets breakpoints directly using the read memory (m) and write memory (M) packets. Some CPU models allow separate modelling of software (memory-based) and hardware (triggerpoint-based) breakpoints in response to gdb packets. Default settings of the attributes force-Z-hw-to-sw? (false), force-Z-sw-to-hw? (false), and fallback-Z-sw-to-hw? (true) cooperate to automatically provide portable triggerpoint-based breakpoints for CPU models without software breakpoint support.

The gdb-pc-mask attribute is used when passing Harvard-encoded PC addresses to the gdb component via a Z packet.

When the operating-mode? attribute is true, the gdb component doesn't handle any cpu traps except for single stepping.

SID Conventions
functional supported -
save/restorenot supported -
triggerpoints supported -


Related Components

The gdb component connects to many other sid components:

Host System

The gdb component prints error and tracing messages to stderr.

Component Reference:

Component: sw-debug-gdb

remote-rxinanypin i/o
remote-txoutanypin i/o
target-txinanypin i/o
process-signaloutenum valuessystem call emulation
gloss-process-signalinenum valuessystem call emulation
trapinoutenum valuessystem call emulation
trap-codeinvarious valuessystem call emulation

namecategorylegal valuesdefault valuebehaviors
connected?-boolean, read-onlyfalseexecution


Debugging with GDB