This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Single-stepping with interrupts enabled.





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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]