Re: Single-stepping with interrupts enabled.

[Richard J Moore <richardj_moore@uk.ibm.com>]

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