Using kernel global variables

Using kernel global variables

[David Wilder]

It is my understanding if we want to access a kernel global variable in 
a tap script we must be in a context that is using the variable.
for example the following script will compile:

probe kernel.function("jiffies_to_timeval")
{
        printf("%x\n", $jiffies);
}

This works because,  jiffies_to_timeval()  uses jiffies in the 
function,  thus in the scope of the probes there exists a DWARF location 
information block for the variable jiffies.

If I change the probe point to do_fork() the probe will not build,  I 
get the error:
"probe do_fork@kernel/fork.c:1369 kernel section=.text pc=0x127b00
semantic error: failed to retrieve location attribute for local 
'jiffies' (dieoffset: 0x18309f): identifier '$jiffies' at global.stp:5:17"
This is because do_fork is not using jiffies.

Is this correct?

Dave....

Re: Using kernel global variables

[Mike Mason]

David Wilder wrote:
> It is my understanding if we want to access a kernel global variable in 
> a tap script we must be in a context that is using the variable.

I believe the variable must be within the *scope* of the probed function.  The function doesn't necessarily have to use the variable for it to be within scope.  A global defined in the same file as the function is automatically within scope.

I don't think exported symbols are within a function's scope from SystemTap's perspective, though the function can see them.  Perhaps the dwarf info doesn't allow for that.

Mike

Re: Using kernel global variables

[David Wilder]

Mike Mason wrote:
> David Wilder wrote:
>> It is my understanding if we want to access a kernel global variable 
>> in a tap script we must be in a context that is using the variable.
>
> I believe the variable must be within the *scope* of the probed 
> function.  The function doesn't necessarily have to use the variable 
> for it to be within scope.  A global defined in the same file as the 
> function is automatically within scope.
>
> I don't think exported symbols are within a function's scope from 
> SystemTap's perspective, though the function can see them.  Perhaps 
> the dwarf info doesn't allow for that.
>
> Mike
>
Thanks for the clarification Mike.
Based on question I have received about global variables I think there 
is a need to access exported variables that are outside the scope of the 
probepoint.  For example accessing a global in a begin or exit probe.   
What do you think of such a feature?
I suspect we would need a way to flag the stap compiler that we are 
referencing a exported global something like using ^var.

Re: Using kernel global variables

[Frank Ch. Eigler]

Mike Mason <mmlnx@us.ibm.com> writes:

> I believe the variable must be within the *scope* of the probed
> function.  The function doesn't necessarily have to use the variable
> for it to be within scope.  A global defined in the same file as the
> function is automatically within scope.

Or even *declared* in the same compilation unit - that should work too.

> I don't think exported symbols are within a function's scope from
> SystemTap's perspective [...]

We could change things to search for globals in other compilation
units too - exported ones first, static ones next (with the obvious
risk of name collisions).

- FChE

Re: Using kernel global variables

[David Wilder]

Frank Ch. Eigler wrote:
> Mike Mason <mmlnx@us.ibm.com> writes:
>
>   
>> I believe the variable must be within the *scope* of the probed
>> function.  The function doesn't necessarily have to use the variable
>> for it to be within scope.  A global defined in the same file as the
>> function is automatically within scope.
>>     
>
> Or even *declared* in the same compilation unit - that should work too.
>
>   
>> I don't think exported symbols are within a function's scope from
>> SystemTap's perspective [...]
>>     
>
> We could change things to search for globals in other compilation
> units too - exported ones first, static ones next (with the obvious
> risk of name collisions).
>
> - FChE
>   
If we could specify that the variable was global it would eliminate the 
chance of name collision.