From: "James Dickens" <jamesd.wi@gmail.com>
To: "Richard J Moore" <richardj_moore@uk.ibm.com>
Cc: "systemtap@sources.redhat.com" <systemtap@sources.redhat.com>
Subject: Re: Single-stepping with interrupts enabled.
Date: Mon, 27 Feb 2006 17:13:00 -0000 [thread overview]
Message-ID: <cd09bdd10602270913j4d5966b2u307c5888036a3fec@mail.gmail.com> (raw)
In-Reply-To: <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
>
>
next prev parent reply other threads:[~2006-02-27 17:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-27 11:29 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 [this message]
2006-02-27 17:34 ` Richard J Moore
2006-02-27 18:18 ` James Dickens
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cd09bdd10602270913j4d5966b2u307c5888036a3fec@mail.gmail.com \
--to=jamesd.wi@gmail.com \
--cc=richardj_moore@uk.ibm.com \
--cc=systemtap@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).