This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Accessing user-space global variables in timer.profile?
- From: agentzh <agentzh at gmail dot com>
- To: Josh Stone <jistone at redhat dot com>
- Cc: David Smith <dsmith at redhat dot com>, systemtap at sourceware dot org
- Date: Tue, 23 Apr 2013 12:08:01 -0700
- Subject: Re: Accessing user-space global variables in timer.profile?
- References: <CAB4Tn6OYi=Vx19H4BLojphuuvjSp2drjvJFd3HxzAGj7=yD5cA at mail dot gmail dot com> <51755D3D dot 6020004 at redhat dot com> <CAB4Tn6OubWF71F9b3hNqXo85h96sr1Rp77-NmZAjmLPt=vAzyA at mail dot gmail dot com> <5175E28B dot 9050500 at redhat dot com>
Hello!
On Mon, Apr 22, 2013 at 6:23 PM, Josh Stone wrote:
>
> So we'll need a @var which at least hints which module holds it, as
> described in http://sourceware.org/bugzilla/show_bug.cgi?id=11096#c5
>
> That's talking about functions, but timer.profile is similarly context-free.
>
Yes! This is exactly what I'm looking for :)
> Once we have @var-module support internally, then we can also play games
> with defaulting the module, using the target object for most process.*
> probes (as @var does now), but perhaps using the -c CMD executable for
> @var used in functions and context-free probes.
>
I'm fine with explicitly specifying the module name in @var() since
I'm generating the stap script on-the-fly with Perl. But this is
feature is a good plus anyway :)
> Hope that makes sense. So it's something feasible, I think, but we
> can't do it just yet.
>
Good to know it is doable :)
Thanks!
-agentzh