Re: Single-stepping with interrupts enabled.

["James Dickens" <jamesd dot wi at gmail dot com>]

On 2/27/06, Richard J Moore <richardj_moore@uk.ibm.com> wrote:
>
>
>
>
> 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.

Seems like enabling interups and allowing signals during the single
step is just asking for problems, dtrace's implementation of your
ideas seems rock stable, I have tested it out by testing  32 dtrace
apps ( plockstat) running at the same time on a SMP system and had no
problems. And others have done even more testing. It would be best to
get basic functionality working, before you move to the next step,
enabling interupts and signals.

James



> - -
> 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
> >
> >
>
>
>