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: http://sourceware.org/ml/systemtap/2013-q2/msg00213.html Feedback welcome!
A modified version of my patch has just been committed: commit bd1fcbad9165da8a96bcffbb1d1d3ca9f7ce3242 Author: Yichun Zhang (agentzh) <agentzh@gmail.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 PR15688). Thanks Josh Stone for reviewing this patch and providing a lot of invaluable suggestions. * parse.cxx: Add support for the optional "module" parameter to the parser. * 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, sdt_uprobe_var_expanding_visitor, and 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. void_statement_reducer. * 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.