A debug event describes an event in a program being debugged or
in a running process. Debug models and process implementations
are required to generate debug events as specified by this class.
The following list defines the events generated for each debug
model element.
The getSource()
method of a debug event
returns the element associated with the event.
Creation events are guaranteed to occur in a top
down order - that is, parents are created before children.
Termination events are guaranteed to occur in a bottom up order -
that is, children before parents. However, termination events are not guaranteed
for all elements that are created. That is, terminate events can be coalesced - a
terminate event for a parent signals that all children have been terminated.
A debug model may define model specific events by specifying a debug event
kind of MODEL_SPECIFIC
. A model specific event is identified by the
event source (i.e. by the debug model that generated the event). The detail of
a model specific event is client defined. Note that model specific events are
not understood by the debug platform, and are thus ignored.
The generic CHANGE
event can be fired at any time by any element.
Generally, a client of a debug model, such as as a UI, can get sufficient
information to update by listening/responding to the other event kinds. However,
if a debug model needs to inform clients of a change that is not specified
by create/terminate/suspend/resume, the CHANGE
event may be used.
For example, generally, the only way a thread or any of its children can change
state between a suspend and resume operation, is if the thread or owning debug
target is terminated. However, if a debug model supports some other operation
that would allow a debug element to change state while suspended, the debug model
would fire a change event for that element. The valid detail codes for a
change event are:
STATE
- indicates the state of an element has changed, but its
children are not affected. A client would use a state change event to update
a label of the affected element, but would not update any children.
CONTENT
- indicates that a debug element's value or contents have
changed in some way. For example, when the value of a variable is changed
explicitly, the variable should fire a content change event.
IProcess
CREATE
- a process has been created and is executing.
TERMINATE
- a process has terminated.
IDebugTarget
CREATE
- a debug target has been created and is ready
to begin a debug session.
TERMINATE
- a debug target has terminated and the debug
session has ended.
SUSPEND
- a debug target has suspended. Event detail provides
the reason for the suspension:
STEP_END
- a request to step has completed
BREAKPOINT
- a breakpoint has been hit
CLIENT_REQUEST
- a client request has caused the target to suspend
(i.e. an explicit call to suspend()
)
UNSPECIFIED
- the reason for the suspend is not specified
RESUME
- a debug target has resumed. Event detail provides
the reason for the resume:
STEP_INTO
- a target is being resumed because of a request to step into
STEP_OVER
- a target is being resumed because of a request to step over
STEP_RETURN
- a target is being resumed because of a request to step return
CLIENT_REQUEST
- a client request has caused the target to be resumed
(i.e. an explicit call to resume()
)
UNSPECIFIED
- The reason for the resume is not specified
IThread
CREATE
- a thread has been created in a debug target.
TERMINATE
- a thread has terminated.
SUSPEND
- a thread has suspended execution. Event detail provides
the reason for the suspension:
STEP_END
- a request to step has completed
BREAKPOINT
- a breakpoint has been hit
CLIENT_REQUEST
- a client request has caused the thread to suspend
(i.e. an explicit call to suspend()
)
EVALUATION
- an expression evaluation has ended that may
have had side effects in the debug target.
EVALUATION_IMPLICIT
- an expression evaluation has ended that
had no side effects in the debug target.
UNSPECIFIED
- the reason for the suspend is not specified
RESUME
- a thread has resumed execution. Event detail provides
the reason for the resume:
STEP_INTO
- a thread is being resumed because of a request to step into
STEP_OVER
- a thread is being resumed because of a request to step over
STEP_RETURN
- a thread is being resumed because of a request to step return
CLIENT_REQUEST
- a client request has caused the thread to be resumed
(i.e. an explicit call to resume()
)
EVALUATION
- an expression evaluation has started that may
have side effects in the debug target.
EVALUATION_IMPLICIT
- an expression evaluation has started that
will have no side effects in the debug target.
UNSPECIFIED
- The reason for the resume is not specified
IStackFrame
- no events are specified for stack frames.
When a thread is suspended, it has stack frames. When a thread resumes,
stack frames are unavailable.
IVariable
- no events are specified for variables.
When a thread is suspended, stack frames have variables. When a thread resumes,
variables are unavailable.
IValue
- no events are specified for values.