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

[Josh Stone <jistone at redhat dot com>]

On 04/22/2013 05:39 PM, agentzh wrote:
> Hello!
> 
> On Mon, Apr 22, 2013 at 8:54 AM, David Smith wrote:
>>
>> 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.
>>
> 
> Because I only sample a process with relatively high CPU usage, the
> odds of swapping out the pages that I'm interested in should be really
> small.
> 
> And I'm fine with getting a runtime warning when the memory page is
> indeed swapped out, for example.
> 
> We are already able to fetch the current userspace backtraces in the
> timer.profile context, for example. And it should be an excellent
> addition if we can access more data like global variables in the
> current user process.

At least with backtraces, we only have to know where modules are loaded,
which we can track at runtime.  For variables, we need to know more at
compile time, including debuginfo which covers it.

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.

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.

Hope that makes sense.  So it's something feasible, I think, but we
can't do it just yet.

Josh