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.
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.
(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.
(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.
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.
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.
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.
(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.
(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 :)
(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.
Commit e8b46a9e46572.