This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Accessing user-space global variables in timer.profile?


On 04/17/2013 07:55 PM, agentzh wrote:
> Hello!
> 
> I'm wondering if it is possible to get @var() working the in
> timer.profile context, just like @cast().
> 
> I've tried using @var("var@file") in a timer.profile handler directly,
> but getting the error
> 
>     Bad $context variable being substituted with literal 0
> 
> Maybe we can specify the path to the executable file as a second
> argument to @var(), just as in @cast()?
> 
> IMHO, it is very useful if we can get access to user-space global
> variables of a particular running process in timer.profile when pid()
> returns the expected pid.
> 
> Could anyone help me here? Thanks in advance!

I believe I see what you are asking here, but I'm afraid it just isn't
possible. When we're in a process.* probe, probes run in the context of
a process, so you can access that process' state and memory. When we're
in a timer.* probe, probes don't really run in the context of any
particular user process, they run in kernel context. At that point, any
specific user process can't really be accessed. That specific user
process might have been swapped out for instance.

So, how to do what you want and be able to sample a user-space global
variable at a timed interval? If the program has any timers itself, the
easiest solution would be to probe the program's timer function.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]