public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
* Single-stepping with interrupts enabled.
@ 2006-02-27 11:29 Richard J Moore
  2006-02-27 13:51 ` Frank Ch. Eigler
  2006-02-27 17:13 ` James Dickens
  0 siblings, 2 replies; 6+ messages in thread
From: Richard J Moore @ 2006-02-27 11:29 UTC (permalink / raw)
  To: systemtap





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

^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-02-27 18:18 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-02-27 11:29 Single-stepping with interrupts enabled Richard J Moore
2006-02-27 13:51 ` Frank Ch. Eigler
2006-02-27 14:05   ` Richard J Moore
2006-02-27 17:13 ` James Dickens
2006-02-27 17:34   ` Richard J Moore
2006-02-27 18:18     ` James Dickens

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).