[Bug translator/10485] auto-path tapset support for process.* probes

["mjw at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From mjw at redhat dot com  2009-08-06 09:27 -------
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.

-- 


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

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