Thursday July 29, 2004

DTrace Instruction Tracing Continues..

Wow, this has me bugged. Using this script ( called itrc.d ):

pid$target:a.out::
{
        printf("%d %016llx",vtimestamp,uregs[R_PC]);
}

# dtrace -s itrc.d -c hello3 > rtrc.hello3

a custom SPARC disassembler, and a really awful perl script, I produced:

Delta NS Address          Instruction   (disassembled)
       0 0000000100000740 bc102000      or      %g0, 0x0, %fp
   12960 0000000100000744 e05ba87f      ldx     [%sp+0x87f], %l0
    7120 0000000100000748 1b000000      sethi   0x0, %o5
    5040 000000010000074c 9a136001      or      %o5, 0x1, %o5
    4960 0000000100000750 9b2b7020      sllx    %o5, 0x1020, %o5
    4640 0000000100000754 13000403      sethi   0x100c00, %o1
    3920 0000000100000758 9212400d      or      %o1, %o5, %o1
    4240 000000010000075c e0226208      stw     %l0, [%o1+ 0x208]
    4240 0000000100000760 a203a887      add     %sp, 0x887, %l1
 ...

I think I'm almost done.

-ejo

(2004-07-29 14:28:54.0) Permalink

DTrace Instruction Tracing

Adam Leventhal pointed out that the DTrace pid provider can instrument user-land instructions, so my interest was piqued enough to give it a whirl last night. The script I ended up with is just stupidly short, I feel like I'm cheating.

pid$target:a.out::
{
        printf("pc %p: %x",uregs[R_PC],*(uint )copyin(uregs[R_PC],4));
}

Using a new DTrace feature, I start the trace and get some output:

# dtrace -c ./hello2 -s itrc.d 
CPU     ID                    FUNCTION:NAME
  0  38695                     _start:entry pc 1000006a0: 91d02038
  0  38696                         _start:0 pc 1000006a0: 91d02038
  0  38697                         _start:4 pc 1000006a4: 91d02038
  0  38698                         _start:8 pc 1000006a8: 91d02038
...

That doesn't look right. The PC's look good, but those aren't the instructions at those addresses. Or are they? I was a bit foggy last night when I started messing with this, so I assumed that I wasn't using copyin() right. Somehow I was getting the address of the DTrace buffer that copyin returns or something. In the cold light of morning things look different. It occurs to me that 91d02038 looks familiar. Yes I know, it's numbers. The crawling itch in my lizard hacker brain was trying to tell me something:

91d02038 <=> ta      %icc, 0x38

What? Your lizard hacker brain doesn't tell you stuff like that? Lucky you. So I was using copyin correctly. I am fetching the instruction at the PC, just not the original instruction. As everybody knows, 0x38 is the DTRACE pid provider trap, so this instruction is the DTrace instrumentation that makes it all work.

I'm feeling moderately clever for having figured that out on only two cups of coffee. :)

-ejo

(2004-07-29 08:17:52.0) Permalink Comments [1]