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).
normal_stop
Notifications
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
is emitted.
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 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.
The symbol file specified by objfile has been loaded. Called with objfile equal to
NULL
to 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 new breakpoint has been created. The argument bpnum is the number of the newly-created breakpoint.
A breakpoint has been destroyed. The argument bpnum is the number of the newly-destroyed breakpoint.
A breakpoint has been modified in some way. The argument bpnum is the number of the modified breakpoint.
A new tracepoint has been created. The argument tpnum is the number of the newly-created tracepoint.
A tracepoint has been destroyed. The argument tpnum is the number of the newly-destroyed tracepoint.
A tracepoint has been modified in some way. The argument tpnum is the number of the modified tracepoint.
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.