It is often convenient to grab a global variable value in a function. But
currently you cannot do that, so you have to grab it in a probe handler and
store it globally or pass it to the function invocation (then you can use the
address of this variable and @cast(var "struct", "module") to extract the
information in the function).
Possible syntax: @global($var, "module")
Global vars that are in scope should be usable already. Are you talking about
globals that are only present in other CUs?
(In reply to comment #1)
> Global vars that are in scope should be usable already.
But in a function there is no scope, so no variable is accessible.
The use case for me is the jstack() function, that would benefit from having
access to some of the globals in libjvm.so. Currently we have a probe on vm_init
to collect those globals and store them for later use in the function. But that
is somewhat limiting the use of the jstack() function (it can only be used after
some probe in the libjvm.so context has been fired first).
I clarified my confusion with mjw on IRC -- in my response I was thinking of
probes on a C function that access global variables, which should work fine. He
is talking about a stap function (with no $ context) that wants to access a
module's global variables.
*** Bug 4906 has been marked as a duplicate of this bug. ***
Now that we have the @var construct as described in PR13784 this could be implemented as an extension of that: @var("varname@cu/src/file.c", "modulename")
I've just submitted a (silly) patch for systemtap that implements this feature:
A modified version of my patch has just been committed:
Author: Yichun Zhang (agentzh) <email@example.com>
Date: Fri Jun 14 17:44:00 2013 -0700
PR11096: Add support for the "module" argument to @var
The notation @var("varname@cuname", "module") is now supported and @var
can thus effectively be used almost everywhere like the context of stap
functions, probe timer.profile, and probe kernel.trace().
Just like @cast, multiple module names can be specified by separating
them with ":", for example, "module1:module2:module3". And they will be
attempted in turn until a match is found.
Refactored the code by introducing atvar_op as suggested by Josh Stone
to make the implementation cleaner. The fields "target_name" and
"cu_name" have been moved from target_symbol to its subclass atvar_op.
@var now searches all the CUs that matches the "cuname" specified for the
variable. And when "cuname" is missing, @var just searches all the CUs.
Accessing global variables in PIE and DSO via @var with either "cuname"
or "module" now mostly works for the default (kernel) runtime (but note
Thanks Josh Stone for reviewing this patch and providing a lot of
* parse.cxx: Add support for the optional "module" parameter to the
* staptree.h: Remove the "target_name" field from target_symbol and make
sym_name() virtual. Define atvar_op which inherits target_symbol. Add
method visit_atvar_op to the visitor classes.
* staptree.cxx: Define visit_atvar_op for the visitor classes. Define
methods of atvar_op.
* tapsets.cxx: Define visit_atvar_op for dwarf_var_expanding_visitor,
tracepoint_var_expanding_visitor. Define dwarf_atvar_expanding_visitor
to run in series with dwarf_cast_expanding_visitor in
dwarf_derived_probe. Add dwarf_atvar_query to handle the DWARF queres
of dwarf_atvar_expanding_visitor. Postpone the processing of @var with
either cu name or module name or both to dwarf_atvar_expanding_visitor
in order to eliminate code duplication.
* elaborate.h: Declare visit_atvar_op for typeresolution_info.
* elaborate.cxx: Define visit_atvar_op for symbol_fetcher,
typeresolution_info, and void_statement_reducer.
* translate.cxx: Define visit_atvar_op for c_unparser.
* testsuite/systemtap.base/: Add many more test cases for @var.