11.6.1 Naming pid Probes

The pid provider actually defines a class of providers. Each process can potentially have its own associated pid provider. For example, a process with ID 123, would be traced by using the pid123 provider.

The module portion of the probe description refers to an object loaded in the corresponding process's address space. To see which objects will be loaded for my_exec or are loaded for process ID 123, use the following commands:

# ldd my_exec
...
# pldd 123
123:  /tmp/my_exec
linux-vdso.so.1
/lib64/libc.so.6
/lib64/ld-linux-x86-64.so.2p

In the probe description, you name the object by the name of the file, not by its full path name. You can also omit the .6 or so.6 suffix. All of the following examples name the same probe:

pid123:libc.so.6:strcpy:entry
pid123:libc.so:strcpy:entry
pid123:libc:strcpy:entry

The first example is the actual name of the probe. The other examples are convenient aliases that are replaced with the full load object name internally.

For the load object of the executable, you can use the a.out alias. The following two probe descriptions name the same probe:

pid123:my_exec:main:return
pid123:a.out:main:return

The function field of the probe description names a function in the module. A user application binary might have several names for the same function. For example, __gnu_get_libc_version might be an alternate name for the function gnu_get_libc_version in libc.so.6. DTrace chooses one canonical name for such a function and uses that name internally.

The following example illustrates how DTrace internally remaps module and function names to a canonical form:

# dtrace -q -n 'pid123:libc:__gnu_get_libc_version:
    { printf("%s\n%s\n", probemod, probefunc)}'
libc.so.6
gnu_get_libc_version

For examples of how to use the pid provider effectively, see Chapter 12, User Process Tracing.