Thanks Phil.
--Vasanth
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
