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

[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

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