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