11. Target Vector Definition

The target vector defines the interface between GDB's abstract handling of target systems, and the nitty-gritty code that actually exercises control over a process or a serial port. GDB includes some 30-40 different target vectors; however, each configuration of GDB includes only a few of them.

11.1 Managing Execution State
11.2 Existing Targets

11.1 Managing Execution State

A target vector can be completely inactive (not pushed on the target stack), active but not running (pushed, but not connected to a fully manifested inferior), or completely active (pushed, with an accessible inferior). Most targets are only completely inactive or completely active, but some support persistent connections to a target even when the target has exited or not yet started.

For example, connecting to the simulator using target sim does not create a running program. Neither registers nor memory are accessible until run. Similarly, after kill, the program can not continue executing. But in both cases GDB remains connected to the simulator, and target-specific commands are directed to the simulator.

A target which only supports complete activation should push itself onto the stack in its to_open routine (by calling push_target), and unpush itself from the stack in its to_mourn_inferior routine (by calling unpush_target).

A target which supports both partial and complete activation should still call push_target in to_open, but not call unpush_target in to_mourn_inferior. Instead, it should call either target_mark_running or target_mark_exited in its to_open, depending on whether the target is fully active after connection. It should also call target_mark_running any time the inferior becomes fully active (e.g. in to_create_inferior and to_attach), and target_mark_exited when the inferior becomes inactive (in to_mourn_inferior). The target should also make sure to call target_mourn_inferior from its to_kill, to return the target to inactive state.

11.2 Existing Targets

11.2.1 File Targets

Both executables and core files have target vectors.

11.2.2 Standard Protocol and Remote Stubs

GDB's file `remote.c' talks a serial protocol to code that runs in the target system. GDB provides several sample stubs that can be integrated into target programs or operating systems for this purpose; they are named `*-stub.c'.

The GDB user's manual describes how to put such a stub into your target code. What follows is a discussion of integrating the SPARC stub into a complicated operating system (rather than a simple program), by Stu Grossman, the author of this stub.

The trap handling code in the stub assumes the following upon entry to trap_low:

1. %l1 and %l2 contain pc and npc respectively at the time of the trap;

2. traps are disabled;

3. you are in the correct trap window.

As long as your trap handler can guarantee those conditions, then there is no reason why you shouldn't be able to "share" traps with the stub. The stub has no requirement that it be jumped to directly from the hardware trap vector. That is why it calls exceptionHandler(), which is provided by the external environment. For instance, this could set up the hardware traps to actually execute code which calls the stub first, and then transfers to its own trap handler.

For the most point, there probably won't be much of an issue with "sharing" traps, as the traps we use are usually not used by the kernel, and often indicate unrecoverable error conditions. Anyway, this is all controlled by a table, and is trivial to modify. The most important trap for us is for ta 1. Without that, we can't single step or do breakpoints. Everything else is unnecessary for the proper operation of the debugger/stub.

From reading the stub, it's probably not obvious how breakpoints work. They are simply done by deposit/examine operations from GDB.

11.2.3 ROM Monitor Interface

11.2.4 Custom Protocols

11.2.5 Transport Layer

11.2.6 Builtin Simulator