[Bug translator/11096] Getting global module vars in functions

[Bug translator/11096] Getting global module vars in functions

[mjw at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11096

--- Comment #5 from Mark Wielaard <mjw at redhat dot com> 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")

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug translator/11096] Getting global module vars in functions

[agentzh at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11096

agentzh <agentzh at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |agentzh at gmail dot com

--- Comment #6 from agentzh <agentzh at gmail dot com> ---
I've just submitted a (silly) patch for systemtap that implements this feature:

http://sourceware.org/ml/systemtap/2013-q2/msg00213.html

Feedback welcome!

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug translator/11096] Getting global module vars in functions

[agentzh at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11096

agentzh <agentzh at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from agentzh <agentzh at gmail dot com> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug translator/11096] New: Getting global module vars in functions

[mjw at redhat dot com]

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")

-- 
           Summary: Getting global module vars in functions
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: mjw at redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=11096

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/11096] Getting global module vars in functions

[jistone at redhat dot com]

------- Additional Comments From jistone at redhat dot com  2009-12-16 19:48 -------
Global vars that are in scope should be usable already.  Are you talking about
globals that are only present in other CUs?

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11096

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/11096] Getting global module vars in functions

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2009-12-16 20:55 -------
(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).

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11096

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/11096] Getting global module vars in functions

[jistone at redhat dot com]

------- Additional Comments From jistone at redhat dot com  2009-12-16 22:54 -------
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.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11096

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/11096] Getting global module vars in functions

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2010-05-21 19:43 -------
*** Bug 4906 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dwilder at us dot ibm dot
                   |                            |com


http://sourceware.org/bugzilla/show_bug.cgi?id=11096

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.