* [Bug translator/11096] Getting global module vars in functions
[not found] <bug-11096-6586@http.sourceware.org/bugzilla/>
@ 2012-03-12 12:21 ` mjw at redhat dot com
2013-05-30 19:23 ` agentzh at gmail dot com
2013-06-27 23:43 ` agentzh at gmail dot com
2 siblings, 0 replies; 7+ messages in thread
From: mjw at redhat dot com @ 2012-03-12 12:21 UTC (permalink / raw)
To: systemtap
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug translator/11096] Getting global module vars in functions
[not found] <bug-11096-6586@http.sourceware.org/bugzilla/>
2012-03-12 12:21 ` [Bug translator/11096] Getting global module vars in functions mjw at redhat dot com
@ 2013-05-30 19:23 ` agentzh at gmail dot com
2013-06-27 23:43 ` agentzh at gmail dot com
2 siblings, 0 replies; 7+ messages in thread
From: agentzh at gmail dot com @ 2013-05-30 19:23 UTC (permalink / raw)
To: systemtap
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug translator/11096] Getting global module vars in functions
[not found] <bug-11096-6586@http.sourceware.org/bugzilla/>
2012-03-12 12:21 ` [Bug translator/11096] Getting global module vars in functions mjw at redhat dot com
2013-05-30 19:23 ` agentzh at gmail dot com
@ 2013-06-27 23:43 ` agentzh at gmail dot com
2 siblings, 0 replies; 7+ messages in thread
From: agentzh at gmail dot com @ 2013-06-27 23:43 UTC (permalink / raw)
To: systemtap
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug translator/11096] Getting global module vars in functions
2009-12-16 11:39 [Bug translator/11096] New: " mjw at redhat dot com
` (2 preceding siblings ...)
2009-12-16 22:55 ` jistone at redhat dot com
@ 2010-05-21 21:39 ` fche at redhat dot com
3 siblings, 0 replies; 7+ messages in thread
From: fche at redhat dot com @ 2010-05-21 21:39 UTC (permalink / raw)
To: systemtap
------- 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug translator/11096] Getting global module vars in functions
2009-12-16 11:39 [Bug translator/11096] New: " mjw at redhat dot com
2009-12-16 19:49 ` [Bug translator/11096] " jistone at redhat dot com
2009-12-16 20:55 ` mjw at redhat dot com
@ 2009-12-16 22:55 ` jistone at redhat dot com
2010-05-21 21:39 ` fche at redhat dot com
3 siblings, 0 replies; 7+ messages in thread
From: jistone at redhat dot com @ 2009-12-16 22:55 UTC (permalink / raw)
To: systemtap
------- 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug translator/11096] Getting global module vars in functions
2009-12-16 11:39 [Bug translator/11096] New: " mjw at redhat dot com
2009-12-16 19:49 ` [Bug translator/11096] " jistone at redhat dot com
@ 2009-12-16 20:55 ` mjw at redhat dot com
2009-12-16 22:55 ` jistone at redhat dot com
2010-05-21 21:39 ` fche at redhat dot com
3 siblings, 0 replies; 7+ messages in thread
From: mjw at redhat dot com @ 2009-12-16 20:55 UTC (permalink / raw)
To: systemtap
------- 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug translator/11096] Getting global module vars in functions
2009-12-16 11:39 [Bug translator/11096] New: " mjw at redhat dot com
@ 2009-12-16 19:49 ` jistone at redhat dot com
2009-12-16 20:55 ` mjw at redhat dot com
` (2 subsequent siblings)
3 siblings, 0 replies; 7+ messages in thread
From: jistone at redhat dot com @ 2009-12-16 19:49 UTC (permalink / raw)
To: systemtap
------- 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2013-06-27 23:43 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-11096-6586@http.sourceware.org/bugzilla/>
2012-03-12 12:21 ` [Bug translator/11096] Getting global module vars in functions mjw at redhat dot com
2013-05-30 19:23 ` agentzh at gmail dot com
2013-06-27 23:43 ` agentzh at gmail dot com
2009-12-16 11:39 [Bug translator/11096] New: " mjw at redhat dot com
2009-12-16 19:49 ` [Bug translator/11096] " jistone at redhat dot com
2009-12-16 20:55 ` mjw at redhat dot com
2009-12-16 22:55 ` jistone at redhat dot com
2010-05-21 21:39 ` fche at redhat dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).