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

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

[mjw at redhat dot com]

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

Mark Wielaard <mjw at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW
         AssignedTo|mjw at redhat dot com       |systemtap at sourceware dot
                   |                            |org

--- Comment #7 from Mark Wielaard <mjw at redhat dot com> 2012-12-18 12:34:44 UTC ---
(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.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

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

[v.ondruch+sourceware-bz at gmail dot com]

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

--- Comment #8 from Vít Ondruch <v.ondruch+sourceware-bz at gmail dot com> 2012-12-18 12:56:37 UTC ---
(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 :)

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

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

[v.ondruch+sourceware-bz at gmail dot com]

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

--- Comment #9 from Vít Ondruch <v.ondruch+sourceware-bz at gmail dot com> 2012-12-20 13:56:07 UTC ---
(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.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

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

[fche at redhat dot com]

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

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://sourceware.org/bugz
                   |                            |illa/show_bug.cgi?id=20264

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

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

[flu at redhat dot com]

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

Felix Lu <flu at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |flu at redhat dot com
         Resolution|---                         |FIXED

--- Comment #10 from Felix Lu <flu at redhat dot com> ---
Commit e8b46a9e46572.

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

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

[fche at redhat dot com]

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.

-- 
           Summary: auto-path tapset support for process.* probes
           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=10485

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

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

[mjw at redhat dot com]

------- 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.

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

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-08-06 14:57 -------
(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.


-- 


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.

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

[mjw at redhat dot com]

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

-- 


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.

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

[mjw at redhat dot com]

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


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.