This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Single-stepping with interrupts enabled.
- From: Richard J Moore <richardj_moore at uk dot ibm dot com>
- To: "systemtap at sources dot redhat dot com" <systemtap at sources dot redhat dot com>
- Date: Mon, 27 Feb 2006 11:27:29 +0000
- Subject: Single-stepping with interrupts enabled.
- Sensitivity:
A couple of weeks ago the topic of single-stepping came up on the
conference call. I said, I'd document the technical consideration over
allowing that to happen - and why it has not been implemented in the
general case.
The problem is down to the need to save state over the single-step, so that
pre- and post-processing either side of the single-step can be correctly
associated with each other. The difficulties that arise when interrupts are
enabled are two-fold, but only manifest themselves when a user-space
instruction is single-stepped.
1) To save state, and to cater for possible recursion one needs a stack.
Since single-stepping a user-space instruction requires a return to
user-space and a stack-switch, there is no natural stack that can be used
to save and restore state. In general a transition from high privilege to
low privilege can only be done using a return mechanism, not a call. On
re-entering the kernel, all state on the kernel stack is lost since we
always enter from a base stack setting as ultimately governed by the TSS in
IA32 or some other equivalent structure in other stack-based architectures.
The answer to this is to implement a hand-managed stack, where we need to
detect the out-of stack condition and revert back to single-stepping with
interrupts disabled until stack space is freed up.
2) the second problem is due to the possibility that the ordering of data
saved on the single-step stack can become invalidated. For example:
Consider the following events concerning two probed locations in user-space
(probe A and probe B).
a) Encounter probe A
b) Save probe processing state
b) Schedule single-stepping of probe A's instruction,
d) Timer interrupt occurs
e) Thread context switch to thread with probe B
f) Encounter probe B
g) Save probe processing state
h) Schedule single-stepping of probe B's instruction.
i) Timer interrupt
j) Thread context switch to thread with probe A
k) Single-step instruction at probe A
l) Enter probe post-processing.
m) Attempt to restore probe processing state.
Here we have a problem: the most recently saved state is that of probe B.
If on the other hand, had probe B single-stepping not been interrupted with
a context switch then we would have found the correct sate, namely that of
probe B.
So, the only options are to disable pre-emption over the single-step or to
implement a per-thread single-step stack.
I can be done, but the implementation is messy and it's a general problem
for all architectures.
- -
Richard J Moore
IBM Advanced Linux Response Team - Linux Technology Centre
MOBEX: 264807; Mobile (+44) (0)7739-875237
Office: (+44) (0)1962-817072