An observer is an entity which is interested in being notified when GDB reaches certain states, or certain events occur in GDB. The entity being observed is called the subject. To receive notifications, the observer attaches a callback to the subject. One subject can have several observers.
observer.c implements an internal generic low-level event notification mechanism. This generic event notification mechanism is then re-used to implement the exported high-level notification management routines for all possible notifications.
The current implementation of the generic observer provides support for contextual data. This contextual data is given to the subject when attaching the callback. In return, the subject will provide this contextual data back to the observer as a parameter of the callback.
Note that the current support for the contextual data is only partial, as it lacks a mechanism that would deallocate this data when the callback is detached. This is not a problem so far, as this contextual data is only used internally to hold a function pointer. Later on, if a certain observer needs to provide support for user-level contextual data, then the generic notification mechanism will need to be enhanced to allow the observer to provide a routine to deallocate the data when attaching the callback.
The observer implementation is also currently not reentrant. In particular, it is therefore not possible to call the attach or detach routines during a notification.
Observer notifications can be traced using the command ‘set debug observer 1’ (see Optional messages about internal happenings).
gdb notifies all
normal_stop observers when the
inferior execution has just stopped, the associated messages and
annotations have been printed, and the control is about to be returned
to the user.
Note that the
normal_stop notification is not emitted when
the execution stops due to a breakpoint, and this breakpoint has
a condition that is not met. If the breakpoint has any associated
commands list, the commands are executed after the notification
The following interfaces are available to manage observers:
Using the function f, create an observer that is notified when ever event occurs, return the observer.
Remove observer from the list of observers to be notified when event occurs.
The following observable events are defined:
The inferior has stopped for real. The bs argument describes the breakpoints were are stopped at, if any. Second argument print_frame non-zero means display the location where the inferior has stopped.
The target's register contents have changed.
The executable being debugged by GDB has changed: The user decided to debug a different program, or the program he was debugging has been modified since being loaded by the debugger (by being recompiled, for instance).
gdb has just connected to an inferior. For ‘run’, gdb calls this observer while the inferior is still stopped at the entry-point instruction. For ‘attach’ and ‘core’, gdb calls this observer immediately after connecting to the inferior, and before any information on the inferior has been printed.
The status of process record for inferior inferior in gdb has changed. The process record is started if started is true, and the process record is stopped if started is false.
The shared library specified by solib has been loaded. Note that when gdb calls this observer, the library's symbols probably haven't been loaded yet.
The shared library specified by solib has been unloaded. Note that when gdb calls this observer, the library's symbols have not been unloaded yet, and thus are still available.
The symbol file specified by objfile has been loaded. Called with objfile equal to
NULLto indicate previously loaded symbol table data has now been invalidated.
The thread specified by t has exited. The silent argument indicates that gdb is removing the thread from its tables without wanting to notify the user about it.
An explicit stop request was issued to ptid. If ptid equals minus_one_ptid, the request applied to all threads. If
ptid_is_pid(ptid)returns true, the request applied to all threads of the process pointed at by ptid. Otherwise, the request applied to the single thread pointed at by ptid.
The target was resumed. The ptid parameter specifies which thread was resume, and may be RESUME_ALL if all threads are resumed.
A breakpoint has been destroyed. The argument b is the pointer to the destroyed breakpoint.
A breakpoint has been modified in some way. The argument b is the modified breakpoint.
The trace frame is changed to tfnum (e.g., by using the
tfindcommand). If tfnum is negative, it means gdb resumes live debugging. The number of the tracepoint associated with this traceframe is tpnum.
The current architecture has changed. The argument newarch is a pointer to the new architecture.
The thread's ptid has changed. The old_ptid parameter specifies the old value, and new_ptid specifies the new value.
The inferior inf has been added to the list of inferiors. At this point, it might not be associated with any process.
The inferior identified by inf has been attached to a process.
Either the inferior associated with inf has been detached from the process, or the process has exited.
The inferior inf has been removed from the list of inferiors. This method is called immediately before freeing inf.
Bytes from data to data + len have been written to the inferior at addr.
Called before a top-level prompt is displayed. current_prompt is the current top-level prompt.
Variable gdb_datadir has been set. The value may not necessarily change.
The parameter of some
setcommands in console are changed. This method is called after a command
setparam value. param is the parameter of
setcommand, and value is the value of changed parameter.
The new trace state variable tsv is created.
The trace state variable tsv is deleted. If tsv is
NULL, all trace state variables are deleted.
The trace state value tsv is modified.