[Bug translator/6880] New: more syntax for shared library probing

[Bug translator/6880] New: more syntax for shared library probing

[fche at redhat dot com]

While the current uprobes syntax can support shared libraries
  probe process("/lib/.....so").... { }
it may be helpful to add some more syntax:

This would resolve the exact library file via heuristics like ldd,
and constrain the uprobes to only named processes.
  probe process("ls").library("libc").function/statement(...) { }

This would search LD_LIBRARY_PATH / /etc/ld.so.conf* for the library
instead of $PATH as for an executable.  Though perhaps we could do
this automatically if the process file name matches "lib*".  Such a
probe could expand to multiple libraries (/lib64 and /lib variants
for example).
  probe library("libc").function/statement(...) { }

-- 
           Summary: more syntax for shared library probing
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: fche at redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=6880

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6880] more syntax for shared library probing

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2008-12-11 16:58 -------
See also the fltrace docs from frysk:
http://sourceware.org/git/?p=frysk.git;a=blob;f=frysk-core/frysk/bindir/ftrace.xml-in

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6880

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6880] more syntax for shared library probing

[mjw at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjw at redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=6880

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6880] more syntax for shared library probing

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-04-22 18:47 -------
One more heuristic:
     probe process("ls").XXX probes
could imply  -d LIB1 -d LIB2 -d LIB3  for all shared libraries
suspected to be used by ls.

One more extension: wildcards in process/unwindsym names
        probe process("/usr/lib/jvm/*.so") { }
and/or  stap -d /usr/lib/mozilla/plugins/*.so


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6880

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6880] more syntax for shared library probing

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2009-05-06 09:50 -------
For tapsets it would also be beneficial if you could set a search paths for the
whole tapset. Say /usr/libexec/gcc/*/4.4.0 for a tapset that defines probes for
various gcc frontend or /usr/lib/gcc/*/4.4.0/ for a tapset that wants to
instrument libraries used by gcc frontend and backends. So some way to add a
#define for the STAP_PATH or STAP_LIBRARY_PATH at the top of a tapset, with some
way for the user to override them if they want to reuse the tapset for an
installation in a different location.

Then the tapset could be written with just probe process("cc1") instead of
having the whole path or regex for the path in each and every probe. The
hotspot.stp has the issue that you have to replace the whole path in each probe
in the tapset when changing installation locations.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6880

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6880] more syntax for shared library probing

[jistone at redhat dot com]

------- Additional Comments From jistone at redhat dot com  2009-05-06 19:29 -------
(In reply to comment #3)
> For tapsets it would also be beneficial if you could set a search paths for
> the whole tapset. Say /usr/libexec/gcc/*/4.4.0 for a tapset that defines probes
> for various gcc frontend or /usr/lib/gcc/*/4.4.0/ for a tapset that wants to
> instrument libraries used by gcc frontend and backends. So some way to add a
> #define for the STAP_PATH or STAP_LIBRARY_PATH at the top of a tapset, with some
> way for the user to override them if they want to reuse the tapset for an
> installation in a different location.

I would actually call that a #pragma, since it affects the compiler behavior. 
Still, normal token-replacing #defines would also be useful to avoid some of the
repetition.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6880

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6880] more syntax for shared library probing

[cap at nsc dot liu dot se]

------- Additional Comments From cap at nsc dot liu dot se  2009-05-20 20:29 -------
I really like that you're currently able to do:
 probe process("/lib/libx.so").function("f")
and by this having a systemwide probe that will catch any task that calls f()
from libx.

If, in the future, this could be improved to:
 probe library("libx").function("f")
with the following improvements:
 * find libx in the current env. (LD_LIBRARY_PATH, ld.so.conf, etc.)
 * work with only the symbol table and not require dwarf
then that would be very nice.

I apologise if this comment was OT, I think/hope it was close enough to be
relevant...

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6880

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6880] more syntax for shared library probing

[srikar at linux dot vnet dot ibm dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |srikar at linux dot vnet dot
                   |                            |ibm dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=6880

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6880] more syntax for shared library probing

[jistone at redhat dot com]

------- Additional Comments From jistone at redhat dot com  2009-10-29 23:50 -------
(In reply to comment #0)
> This would resolve the exact library file via heuristics like ldd,
> and constrain the uprobes to only named processes.
>   probe process("ls").library("libc").function/statement(...) { }

I was recently reminded of the perils of ldd vs. a custom --dynamic-linker, so
we should tread carefully here...

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6880

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6880] more syntax for shared library probing

[scox at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|systemtap at sources dot    |scox at redhat dot com
                   |redhat dot com              |
             Status|NEW                         |ASSIGNED


http://sourceware.org/bugzilla/show_bug.cgi?id=6880

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.