This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Single-stepping with interrupts enabled.
- From: "James Dickens" <jamesd dot wi at gmail dot com>
- To: "Richard J Moore" <richardj_moore at uk dot ibm dot com>
- Cc: "systemtap at sources dot redhat dot com" <systemtap at sources dot redhat dot com>
- Date: Mon, 27 Feb 2006 11:13:44 -0600
- Subject: Re: Single-stepping with interrupts enabled.
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MchvydcwJIZisl+DF/qM00JX2NaJELXOipEStzg+K1b4LbK4bGR8tAfeHUL7Sv03uMtpmHYL21+akoCnBteEEsYWEzrtqETATmAaLMRe6amduiNkesobZH7vHT1NzdspySnaP3yJSI16RO+Vg3M2FMJxzcRONLPPVwinOTHanqM=
- References: <OFB9B3CACE.BD84F585-ON80257122.003BE810-80257122.003EF137@uk.ibm.com>
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
>
>