Bug 10485

Summary: auto-path tapset support for process.* probes
Product: systemtap Reporter: Frank Ch. Eigler <fche>
Component: translatorAssignee: Unassigned <systemtap>
Status: RESOLVED FIXED    
Severity: normal CC: flu, v.ondruch+sourceware-bz
Priority: P2    
Version: unspecified   
Target Milestone: ---   
See Also: https://sourceware.org/bugzilla/show_bug.cgi?id=20264
Host: Target:
Build: Last reconfirmed:

Description Frank Ch. Eigler 2009-08-05 17:11:55 IST
For separately-installed packages that may carry systemtap tapset
files, and even for systemtap itself (bug #10204), it's desirable
to have an additional path resolution mechanism for process() probes.
Specifically, it's undesirable to have to change the .stp files, just
because the installation prefix may have changed (so an executable or
library ended up in /usr/local/libexec/foo vs. /usr/libexec/foo).

So, consider this.  Let's extend the tapset search logic, so that
an extra subdirectory is searched: "$prefix/share/systemtap/tapset/PATH".
Underneath that, a subdirectory structure parallel to "/" would appear,
kind of like "/usr/src/debug" on fedora.  In there, tapset files may refer
to process("name") probes.  Those "name" strings will generally be unqualified
as written, but the translator would insert the "/subpath/" parts.  So:

$prefix/share/systemtap/tapset/PATH/usr/libexec/foobar.stp:
   probe process("my-program"). ... { }
would be treated as
   probe foobar = process("/usr/libexec/my-program") ... { }

This would allow separately built applications / shlibs to drop in additional
files under .../tapset/PATH/... and have stap find the binaries without an
further ado.
Comment 1 Mark Wielaard 2009-08-06 09:27:07 IST
That would be a nice addition. It would certainly help with the java hotspot.stp
tapset.

Two a couple of issues though that I am not 100% sure of how to tackle. And of
course java shows them all :) You can have multiple versions, multiple
architectures and multiple dynamically dlloaded shared libraries. All however
would like to use the same probe alias names in their tapset.

So you have the following probe alias:

probe hotspot.gc_begin =
  process("[version-x/arch-y/jitengine-z/]libjvm.so").mark("gc__begin")
{
  [define some convenience variables for probe...]
}

Where version-x can be 6 or 7, arch can be i686 or x86_64 and jitengine can be
client or server (dynamocally loaded at runtime depending on the mood of the jvm
and/or some command line flags given by the user.

Actually we don't handle the version part yet, but people are complaining they
can use either 6 or 7, but not both at once because the tapset needs to be
installed in the same place.

The arch we handle by placing the hotspot.stp under either i686 or x86_64 (btw,
these arch dirs seem kernel specific, not userland specific, which seems to be
somewhat confusing).

Currently there is just one big hotspot.stp tapset that duplicates the process
line multiple times for each jitengine possibly in use. This has to be done
because a probe alias name can only be defined once. So the above scheme
wouldn't help this case because even if we placed multiple hotspot.stp tapsets
under different directories for each libjvm.so they would conflict because they
use the same probe alias name.
Comment 2 Frank Ch. Eigler 2009-08-06 14:57:34 IST
(In reply to comment #1)
> [...]
> Currently there is just one big hotspot.stp tapset that duplicates the process
> line multiple times for each jitengine possibly in use. This has to be done
> because a probe alias name can only be defined once. 

We could relax that constraint.
Comment 3 Mark Wielaard 2009-08-07 09:20:27 IST
(In reply to comment #2)
> (In reply to comment #1)
> > This has to be done because a probe alias name can only be defined once. 
> 
> We could relax that constraint.

I added a new bug #10495 for this.
Comment 4 Mark Wielaard 2011-12-16 19:21:52 IST
A similar issue is helper tapset functions that are process/module specific. For example with java the jstack() helper functions. Those rely on specifics of the libjvm.so being probed.
Comment 5 Vít Ondruch 2012-12-18 12:11:25 IST
IMO, the proposed path is not enough. In /usr/share, there should not be any platform specific stuff, but unfortunately, 32b and 64b libraries are placed on different locations, i.e. there is /usr/lib/libruby.so.2.0 librarary on 32b systems and /usr/lib64/libruby.so.2.0 on 64b systems. So it means there would be needed platform specific paths.

Currently Ruby have to provide libruby-32.stp and libruby-64.stp files to support both architectures and there is no better way then to place them into /usr/share, which violates FHS.

Please note that this is not just issue of Ruby, but for Python as well and probably others.
Comment 6 Vít Ondruch 2012-12-18 12:19:43 IST
I am not even sure if SystemTap can handle libruby-64.stp and libruby-32.stp files both present in tapset directory, both contains the same probe definitions and differs just by process path.
Comment 7 Mark Wielaard 2012-12-18 12:34:44 IST
(In reply to comment #6)
> I am not even sure if SystemTap can handle libruby-64.stp and libruby-32.stp
> files both present in tapset directory, both contains the same probe
> definitions and differs just by process path.

That should work fine. It will simultaneously probe both variants.
Comment 8 Vít Ondruch 2012-12-18 12:56:37 IST
(In reply to comment #7)
> (In reply to comment #6)
> > I am not even sure if SystemTap can handle libruby-64.stp and libruby-32.stp
> > files both present in tapset directory, both contains the same probe
> > definitions and differs just by process path.
> 
> That should work fine. It will simultaneously probe both variants.

Thank you. Will sleep better now :)
Comment 9 Vít Ondruch 2012-12-20 13:56:07 IST
(In reply to comment #5)
To solve my issues, there is possible to use wild cards, e.g. process("/usr/lib*/libruby.so.2.0") which seems to be enough to make my .stp file platform independent.
Comment 10 Felix Lu 2016-08-03 18:16:00 IST
Commit e8b46a9e46572.