I tried something that seems like it should be legal, tonight, but it
keeps failing, and I''m unclear why.
I''d like to instrument a particular function entry in a userland
program
using the pid provider; specifically, get_propval_by_name() in prtconf.
The function exists, and is called:
dtrace -qn ''pid$target:prtconf::entry{printf("%s:%s:%s:%s\n",
probeprov, probemo
d, probefunc, probename);}'' -c "prtconf -b"
pid758:prtconf:_start:entry
pid758:prtconf:__fsr:entry
pid758:prtconf:__fsr:entry
pid758:prtconf:setprogname:entry
pid758:prtconf:do_productinfo:entry
pid758:prtconf:dump_prodinfo:entry
pid758:prtconf:get_propval_by_name:entry
pid758:prtconf:get_propval_by_name:entry
pid758:prtconf:get_propval_by_name:entry
pid758:prtconf:get_propval_by_name:entry
but if I add the function name, to just see that one:
dtrace -qn
''pid$target:prtconf:get_propval_by_name:entry{printf("%s:%s:%s:%s\n",
probeprov, probemod, probefunc, probename);}'' -c "prtconf
-b"
dtrace: invalid probe specifier
pid$target:prtconf:get_propval_by_name:entry{printf("%s:%s:%s:%s\n",
probeprov,
probemod, probefunc, probename);}: failed to lookup
''get_propval_by_name'' in
module ''prtconf''
Why can''t I name the function?
Dan Mick wrote:> Why can''t I name the function?oh. because prtconf is really isaexec. Using /usr/sbin/amd64/prtconf as the command allows it to work. Still, though: if the fbt probes work at all, then dtrace must know the function names by the time it inserts them; is the problem here that naming the probe tries to evaluate the function name too early?
max at bruningsystems.com
2007-Apr-12 06:34 UTC
[dtrace-discuss] Weird problem with pid provider
Hi Dan,
I have also run into this problem dtracing mdb. Are you running on
amd64 or sparc?
If so, try
dtrace -n ''pic$target:prtconf:get_propval_by_name:entry{}'' -c
"/usr/sbin/amd64/prtconf -b"
(Or substitute sparcv9 for amd64). This works for me.
max
Dan Mick wrote:> I tried something that seems like it should be legal, tonight, but it
> keeps failing, and I''m unclear why.
>
> I''d like to instrument a particular function entry in a userland
program
> using the pid provider; specifically, get_propval_by_name() in prtconf.
> The function exists, and is called:
>
> dtrace -qn
''pid$target:prtconf::entry{printf("%s:%s:%s:%s\n",
> probeprov, probemo
> d, probefunc, probename);}'' -c "prtconf -b"
>
> pid758:prtconf:_start:entry
> pid758:prtconf:__fsr:entry
> pid758:prtconf:__fsr:entry
> pid758:prtconf:setprogname:entry
> pid758:prtconf:do_productinfo:entry
> pid758:prtconf:dump_prodinfo:entry
> pid758:prtconf:get_propval_by_name:entry
> pid758:prtconf:get_propval_by_name:entry
> pid758:prtconf:get_propval_by_name:entry
> pid758:prtconf:get_propval_by_name:entry
>
> but if I add the function name, to just see that one:
>
> dtrace -qn
>
''pid$target:prtconf:get_propval_by_name:entry{printf("%s:%s:%s:%s\n",
> probeprov, probemod, probefunc, probename);}'' -c "prtconf
-b"
>
> dtrace: invalid probe specifier
>
pid$target:prtconf:get_propval_by_name:entry{printf("%s:%s:%s:%s\n",
> probeprov, probemod, probefunc, probename);}: failed to lookup
> ''get_propval_by_name'' in module
''prtconf''
>
> Why can''t I name the function?
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
>
On Wed, Apr 11, 2007 at 11:19:15PM -0700, Dan Mick wrote:> Still, though: if the fbt probes work at all, then dtrace must know the > function > names by the time it inserts them; is the problem here that naming the probe > tries to evaluate the function name too early?The pid provider doesn''t know that the traced executable is planning on exec''ing a binary of the same name so there''s really nothing dtrace(1M) can do to search out some other binary that might contain the given function. When a traced process does an exec(2), the dtrace command will reevaluate the probe description to see if there are new probes that match. Adam -- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
Adam Leventhal wrote:> On Wed, Apr 11, 2007 at 11:19:15PM -0700, Dan Mick wrote: >> Still, though: if the fbt probes work at all, then dtrace must know the >> function >> names by the time it inserts them; is the problem here that naming the probe >> tries to evaluate the function name too early? > > The pid provider doesn''t know that the traced executable is planning on > exec''ing a binary of the same name so there''s really nothing dtrace(1M) > can do to search out some other binary that might contain the given > function.Yeah...I was thinking something like "if it doesn''t match now, keep it around in case an exec makes it show up". something like what the .so processing must do, but for a.out/execname.> When a traced process does an exec(2), the dtrace command will reevaluate > the probe description to see if there are new probes that match.Then, should -Z have helped? It didn''t seem to.
On Thu, Apr 12, 2007 at 01:50:14PM -0700, Dan Mick wrote:> >The pid provider doesn''t know that the traced executable is planning on > >exec''ing a binary of the same name so there''s really nothing dtrace(1M) > >can do to search out some other binary that might contain the given > >function. > > Yeah...I was thinking something like "if it doesn''t match now, keep it > around in case an exec makes it show up". something like what the .so > processing must do, but for a.out/execname. > > >When a traced process does an exec(2), the dtrace command will reevaluate > >the probe description to see if there are new probes that match. > > Then, should -Z have helped? It didn''t seem to.If you''ve fully specified a probe (module and function) then -Z won''t have any effect: dtrace(1M) assumes that you''d like to be notified if a probe will apparently never be matched. You can solve this by omitting the module part of the probe. I''d be loath to change this behavior since fully qualified probes that match nothing are usually a mistake. Adam -- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
On Thu, Apr 12, 2007 at 02:05:12PM -0700, Adam Leventhal wrote:> > Then, should -Z have helped? It didn''t seem to. > > If you''ve fully specified a probe (module and function) then -Z won''t have > any effect: dtrace(1M) assumes that you''d like to be notified if a probe > will apparently never be matched. You can solve this by omitting the module > part of the probe. I''d be loath to change this behavior since fully > qualified probes that match nothing are usually a mistake.Hmmm, not when you''re dealing with modules for pluggable systems (like PAM, say) and you want a probe for a specific module, but it won''t be loaded (via dlopen()) until it''s needed. Not specifying a module then wouldn''t help because there may be multiple modules providing the same symbol.
On Thu, Apr 12, 2007 at 04:08:35PM -0500, Nicolas Williams wrote:> > If you''ve fully specified a probe (module and function) then -Z won''t have > > any effect: dtrace(1M) assumes that you''d like to be notified if a probe > > will apparently never be matched. You can solve this by omitting the module > > part of the probe. I''d be loath to change this behavior since fully > > qualified probes that match nothing are usually a mistake. > > Hmmm, not when you''re dealing with modules for pluggable systems (like > PAM, say) and you want a probe for a specific module, but it won''t be > loaded (via dlopen()) until it''s needed. Not specifying a module then > wouldn''t help because there may be multiple modules providing the same > symbol.In that case, you should be fine since the module isn''t yet loaded. If DTrace finds the module (shared object or executable) and can''t find the symbol, it will report it as an error. Adam -- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
On Thu, Apr 12, 2007 at 02:19:39PM -0700, Adam Leventhal wrote:> On Thu, Apr 12, 2007 at 04:08:35PM -0500, Nicolas Williams wrote: > > > If you''ve fully specified a probe (module and function) then -Z won''t have > > > any effect: dtrace(1M) assumes that you''d like to be notified if a probe > > > will apparently never be matched. You can solve this by omitting the module > > > part of the probe. I''d be loath to change this behavior since fully > > > qualified probes that match nothing are usually a mistake. > > > > Hmmm, not when you''re dealing with modules for pluggable systems (like > > PAM, say) and you want a probe for a specific module, but it won''t be > > loaded (via dlopen()) until it''s needed. Not specifying a module then > > wouldn''t help because there may be multiple modules providing the same > > symbol. > > In that case, you should be fine since the module isn''t yet loaded. If > DTrace finds the module (shared object or executable) and can''t find the > symbol, it will report it as an error.Ah, I misread then. (Though I wonder about multiple versions of a module where the version number is in the module path, but not the soname. This isn''t something one would recommend, but it''s possible.)
Adam Leventhal wrote:>> Then, should -Z have helped? It didn''t seem to. > > If you''ve fully specified a probe (module and function) then -Z won''t have > any effect: dtrace(1M) assumes that you''d like to be notified if a probe > will apparently never be matched. You can solve this by omitting the module > part of the probe. I''d be loath to change this behavior since fully > qualified probes that match nothing are usually a mistake.Indeed....so the answer to my particular question is "use -Z, but don''t use the module name". I see, and I guess I understand why.