Figure 2.3 shows the high level sequence diagram for GDB in response to the target command.
The target command maps directly on to the
current target to_open
. A typical
implementation establishes physical connection to the target (for
example by opening a TCP/IP link to a remote target). For a remote
target, it then typically calls start_remote
,
which waits for the target to stop (using the current target
to_wait
function), determines the reason for
stopping (handle_inferior_event
) and then marks
this as a normal stop (normal_stop
).
handle_inferior_event
is a central function in
GDB. Whenever control is returned to GDB, via the target
to_wait
function, it must determine what has
happened and how it should be handled. Figure 2.4 shows the behavior of
handle_inferior_event
in response to the
target command.
handle_inferior_event
needs to establish the
program counter at which execution stopped, so calls
read_pc_pid
. Since the program counter is a
register, this causes creation of a register cache, for which the
type of each register must be determined by
gdbarch_register_type
(a one-off exercise,
since this never changes). Having determined register types, the
register cache is populated with the value of the program counter by
calling the current target to_fetch_registers
for the relevant register.
handle_inferior_event
then determines if the
stop was due to a breakpoint or watchpoint. The function
watchpoints_triggered
uses the target
target_stopped_by_watchpoint
to determine if it
was a watchpoint which triggered the stop.
The call to normal_stop
also invokes the
struct gdbarch functions, calling gdbarch_unwind_pc
to establish the current program counter and and frame sniffer
functions to establish the frame sniffer stack.