Bug 11096 - Getting global module vars in functions
Summary: Getting global module vars in functions
Alias: None
Product: systemtap
Classification: Unclassified
Component: translator (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Unassigned
: 4906 (view as bug list)
Depends on:
Reported: 2009-12-16 11:39 UTC by Mark Wielaard
Modified: 2013-06-27 23:43 UTC (History)
2 users (show)

See Also:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Mark Wielaard 2009-12-16 11:39:15 UTC
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")
Comment 1 Josh Stone 2009-12-16 19:48:49 UTC
Global vars that are in scope should be usable already.  Are you talking about
globals that are only present in other CUs?
Comment 2 Mark Wielaard 2009-12-16 20:55:08 UTC
(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).
Comment 3 Josh Stone 2009-12-16 22:54:58 UTC
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.
Comment 4 Frank Ch. Eigler 2010-05-21 19:43:02 UTC
*** Bug 4906 has been marked as a duplicate of this bug. ***
Comment 5 Mark Wielaard 2012-03-12 12:21:18 UTC
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")
Comment 6 agentzh 2013-05-30 19:22:56 UTC
I've just submitted a (silly) patch for systemtap that implements this feature:


Feedback welcome!
Comment 7 agentzh 2013-06-27 23:43:03 UTC
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
    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
    * 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.
    * 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.