DTrace: pid provider

转载自：http://solaris.reys.net/english/archives/55-DTrace-pid-provider.html

Quite ofter we'd like to know what happens to a particular process on a
system, and if we're using DTrace for our investigation, we'd probably
use the $target variable (I've already spoked about it
in the past) or simply specify the process identifier (pid) in some
predicates of our probes, thus pointing to DTrace that we're after only
a certain process. $target variable still can and should be used when creating our probes with pid provider.





For DTrace beginners it's quite a common and good practice. But there is a better way: using the pid provider.



As it's explained in the official DTrace guide, pid provider
isn't just a provider, but in fact is a whole class of providers. And,
as the name suggests, it provides us with probes related to a certain
process.



For instance, pid737 provider allows us to trace everything happening
within a process with pid of 737. What's really cool about this provide
- it's not only easier to scope our interest, but it also gets much
easier to see how where certain probes originate from (what libraries
provide certain functions used by our process, read on - I'll explain
it a bit later).



Such a way of looking at a certain process, in contrast to using predicates like /pid == $target/,
is more correct. Instead of enabling all the specified probes by
default, and then using predicates for each probe firing for each
process on the system only to see whether we're interested in a given
process, DTrace won't even look at other processes - and pid737 will
make sure that all the probes specified will be enabled and possibly
fired only for the specified process.



We already know how to get the list of all the probes known to DTrace. I've explained
it a while ago. The thing you need to remember about the pid provider
is this: after you've used pid provider in some probes for a process, dtrace -l
will start reporting you these probes at the end of all the available
probes. They've been dynamically allocated just for you. If the process
in question dies or finishes, all the dynamically allocated probes for
its pid provider will disappear.



One more thing I really like about pid provider - modules used in
probes are in fact libraries used for the execution of the process
you're looking at. This gives you a wonderful opportunity of observing
only what's been done in your process by functions of a particular
library. Very useful.



Right, enough of theory - here's an example. First, we create a simple bit of "Hello, world!" code in C:

CODE:

void main() {

        printf("Hello, world!
");

}

After you compile it, let's get going with out DTrace script:

CODE:

#!/usr/sbin/dtrace -s

#pragma D option quiet



BEGIN {

printf("Target pid: %d
", $target);

}



pid$target:::entry {

printf("%s:%s:%s:%s
", probeprov, probemod, probefunc, probename);

}

Save the script, make it executable, and start it, specifying our hello as a command to start:

CODE:

$ ./pid-global.d -c ./hello | more

Target pid: 1059

Hello, world!

pid1059:LM1`ld.so.1:call_array:entry

pid1059:LM1`ld.so.1:call_init:entry

pid1059:LM1`ld.so.1:leave:entry

pid1059:LM1`ld.so.1:fmap_setup:entry

pid1059:LM1`ld.so.1:munmap:entry

pid1059:LM1`ld.so.1:rt_bind_clear:entry

pid1059:LM1`ld.so.1:_rt_bind_clear:entry

pid1059:LM1`ld.so.1:rt_mutex_unlock:entry

pid1059:LM1`ld.so.1:_rt_null:entry

pid1059:LM1`ld.so.1:rt_bind_clear:entry

pid1059:LM1`ld.so.1:_rt_bind_clear:entry

pid1059:libc.so.1:libc_init:entry

pid1059:libc.so.1:__amd64id:entry

pid1059:libc.so.1:atexit:entry

pid1059:libc.so.1:lmalloc:entry

pid1059:libc.so.1:getbucketnum:entry

...

You see this list of probes? I won't give you the full list - it's
going to be almost a 1000 lines, but I hope you get the idea. It's also
a perfect opportunity to see how easy it's going to be for you to track
probes of a particular library.



Back to our example, it's obvious what I'm going to do now: I'd like to get our printf caught with a probe.

CODE:

#!/usr/sbin/dtrace -s

#pragma D option quiet



BEGIN {

printf("Target pid: %d
", $target);

}



pid$target::printf:entry {

printf("%s:%s:%s:%s
", probeprov, probemod, probefunc, probename);

printf("Argument: %s
", copyinstr(arg0));

}

If we start tihs script, here's what you'll get:

CODE:

$ ./pid-printf.d -c ./hello

Target pid: 1201

Hello, world!

pid1201:libc.so.1:printf:entry

Argument: Hello, world!

           

：