Thursday July 29, 2004

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]