This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Single-stepping with interrupts enabled.
- From: Richard J Moore <richardj_moore at uk dot ibm dot com>
- To: "James Dickens" <jamesd dot wi at gmail dot com>
- Cc: "systemtap at sources dot redhat dot com" <systemtap at sources dot redhat dot com>
- Date: Mon, 27 Feb 2006 17:32:09 +0000
- Subject: Re: Single-stepping with interrupts enabled.
- Sensitivity:
Effectively we do that (and I note that the Dtrace guys read my paper on
how to do this ;-)), however to do better than that one might consider
enabling interrupts or allowing signals during the single-step.
- -
Richard J Moore
IBM Advanced Linux Response Team - Linux Technology Centre
MOBEX: 264807; Mobile (+44) (0)7739-875237
Office: (+44) (0)1962-817072
"James Dickens"
<jamesd.wi@gmai
l.com> To
Richard J Moore/UK/IBM@IBMGB
27/02/2006 cc
17:13 "systemtap@sources.redhat.com"
<systemtap@sources.redhat.com>
bcc
Subject
Re: Single-stepping with interrupts
enabled.
On 2/27/06, Richard J Moore <richardj_moore@uk.ibm.com> wrote:
>
>
>
>
> 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.
A lot of problems can be solved if you use some of the methodology
that dtrace uses. Where they do most single stepping in a scratch
space and defers signals till after were done with our probing.
http://cvs.opensolaris.org/source/xref/on/usr/src/uts/intel/dtrace/fasttrap_isa.c
44 * Most instructions' execution is not dependent on their
address; for these
45 * instrutions it is sufficient to copy them into the user
process's address
46 * space and execute them. To effectively single-step an
instruction in
47 * user-land, we copy out the following sequence of
instructions to scratch
48 * space in the user thread's ulwp_t structure.
49 *
50 * We then set the program counter (%eip or %rip) to point to
this scratch
51 * space. Once execution resumes, the original instruction is
executed and
52 * then control flow is redirected to what was originally the
subsequent
53 * instruction. If the kernel attemps to deliver a signal while
single-
54 * stepping, the signal is deferred and the program counter is
moved into the
55 * second sequence of instructions. The second sequence ends
in a trap into
56 * the kernel where the deferred signal is then properly
handled and delivered.
57 *
58 * For instructions whose execute is position dependent, we
perform simple
59 * emulation. These instructions are limited to control transfer
60 * instructions in 32-bit mode, but in 64-bit mode there's the
added wrinkle
61 * of %rip-relative addressing that means that almost any
instruction can be
62 * position dependent. For all the details on how we emulate
generic
63 * instructions included %rip-relative instructions, see the code
in
64 * fasttrap_pid_probe() below where we handle instructions of type
65 * FASTTRAP_T_COMMON (under the header: Generic Instruction
Tracing).
66 */
James Dickens
uadmin.blogspot.com
[snipped]
>
> - -
> Richard J Moore
> IBM Advanced Linux Response Team - Linux Technology Centre
> MOBEX: 264807; Mobile (+44) (0)7739-875237
> Office: (+44) (0)1962-817072
>
>