Figure 2.3 shows the high level sequence diagram for GDB in response to the target command.

Figure 2.3.  High level sequence diagram for the GDB 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.

Figure 2.4.  handle_inferior_event sequence diagram in response to the GDB 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.