Think of it this way: the fbt provider instruments function boundaries in the
kernel's address space; the pid provider does the same (and more) for
processes. There is one kernel address space, but many process address spaces.
Implementing pid*::dlopen:entry has at least two huge implications: stopping
and instrumenting every current process in the system; and instrumenting every
new process address space over time (i.e. dealing with fork and exec). The
impact on system performance would be huge.
Some have been creative in scripting around these challenges for small,
specific sets of processes (e.g. tracing fork and exec syscalls, identifying
target processes, stopping them, calling system() to start a pid provider
scripts on them, etc) but you really have to want to do that :)
Another starting point for your current need might be to trace file opens
across the system, predicating on file names that look like shared libraries.
----- Reply message -----
From: "Vasanth Bhat" <vasa...@sun.com>
To: <dtrace-discuss@opensolaris.org>
Subject: [dtrace-discuss] Using regexp for $pid in pid provider
Date: Sat, Feb 5, 2011 08:59
Hi
Is it possible to use regular expression or wild cards or
blank in for the "$pid" in the probe description in the pid privider?
Suppose, if I want to monitor the libraries beling loaded dynamically
by different processes at runtime, and if I use the following probe
description, it doesn't seem to help.
pid*::dlopen:entry
OR
::dlopen:entry
Are there any approaches ( other provider) that need to be used, if we
want to monitor use of an library API across systemwide?
Thanks
Vasanth
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
