Fix state.c handling of state dump thread state
authorMathieu Desnoyers <mathieu.desnoyers@efficios.com>
Tue, 15 Mar 2011 00:30:55 +0000 (20:30 -0400)
committerMathieu Desnoyers <mathieu.desnoyers@efficios.com>
Tue, 15 Mar 2011 00:30:55 +0000 (20:30 -0400)
commitf044974e2d3eee32dfca594025cad1afc790c84f
tree6bd7eb1f1ff56653ccddb274bfbcfd69f5813c40
parent174cf7f84593477bec99f9ae615b2f5f218bb93c
Fix state.c handling of state dump thread state

Introduce the states:

LTTV_STATE_MAYBE_USER_MODE
LTTV_STATE_MAYBE_SYSCALL
LTTV_STATE_MAYBE_TRAP

tagged by the state dump, and then checked by the fixup perform at statedump
end. The controlflow view shows "unknown" state when these states are seen, but
the fixup knows that it is safe to flag the states as "USER_MODE" and "SYSCALL"
after quiescent state has been reached.

Note that we might incorrectly assign "MAYBE_SYSCALL", and then "SYSCALL" to a
thread preempted in TRAP mode. We should find a way to add instrumentation to
the kernel so the state dump tells us how to differ between these two modes.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
lttv/lttv/state.c
lttv/lttv/state.h
lttv/modules/gui/controlflow/eventhooks.c
This page took 0.02349 seconds and 4 git commands to generate.