From: Josh Stone <jistone@redhat.com>
To: agentzh <agentzh@gmail.com>
Cc: David Smith <dsmith@redhat.com>, systemtap@sourceware.org
Subject: Re: Accessing user-space global variables in timer.profile?
Date: Mon, 03 Jun 2013 23:21:00 -0000 [thread overview]
Message-ID: <51AD24EB.5000708@redhat.com> (raw)
In-Reply-To: <51AD1B9A.3050907@redhat.com>
(resending this followup, because my client glitched and I don't see
that this made it to the list...)
On 06/03/2013 03:41 PM, Josh Stone wrote:
>> 2. There's some code duplication between this early @var expansion and
>> the existing dwarf_var_expanding_visitor. Maybe we could merge them
>> two or just abstract out some common logic?
>
> I think that could be helped a little by deferring the current @var
> expansion into your new visitor. This would be much like how the
> dwarf_var_expanding_visitor::visit_cast_op() only sets the module name,
> so dwarf_cast_expanding_visitor has the right context later.
Ugh, now it occurs to me that this suggestion only makes sense for @var
globals, where there's a cu_name and no module name. For plain
@var("name") it could be a local variable, and this really does need to
be processed on the spot in dwarf_var_expanding_visitor.
Here's a possible outline to accomplish that with separate atvar_op:
* Make target_symbol::sym_name virtual, and make this one deal only with
the plain ->name case.
* Add the atvar_op::sym_name override which does target_name munging.
* Add something like:
void
dwarf_var_expanding_visitor::visit_atvar_op (atvar_op *e)
{
if (e->module.empty() && e->cu_name.empty())
{
// process like any other local
// e->sym_name() will do the right thing
visit_target_symbol(e);
return;
}
// Fill in our current module context if needed
if (e->module.empty())
e->module = q.dw.module_name;
}
* Then dwarf_atvar_query/visitor can handle the globals that make it
through.
Hope I'm not over-engineering this... what do you think?
next prev parent reply other threads:[~2013-06-03 23:21 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-18 0:55 agentzh
2013-04-22 15:54 ` David Smith
2013-04-23 0:39 ` agentzh
2013-04-23 1:23 ` Josh Stone
2013-04-23 19:08 ` agentzh
2013-05-30 4:00 ` agentzh
2013-06-01 7:46 ` agentzh
2013-06-03 23:19 ` Josh Stone
2013-06-07 23:23 ` agentzh
2013-06-03 22:41 ` Josh Stone
2013-06-03 23:21 ` Josh Stone [this message]
2013-06-07 23:20 ` agentzh
2013-06-15 2:18 ` [PATCH] PR11096: Add support for the "module" argument to @var Yichun Zhang (agentzh)
2013-06-18 1:06 ` Josh Stone
2013-06-24 7:52 ` [PATCH v2 0/1] " Yichun Zhang (agentzh)
2013-06-24 7:53 ` [PATCH v2 1/1] " Yichun Zhang (agentzh)
2013-06-25 1:16 ` Josh Stone
2013-06-26 5:42 ` [PATCH v3 0/1] " Yichun Zhang (agentzh)
2013-06-26 5:43 ` [PATCH v3 1/1] " Yichun Zhang (agentzh)
2013-06-26 22:40 ` Josh Stone
2013-06-27 19:35 ` Yichun Zhang (agentzh)
2013-06-27 23:31 ` Yichun Zhang (agentzh)
2013-06-03 23:52 ` Accessing user-space global variables in timer.profile? Josh Stone
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51AD24EB.5000708@redhat.com \
--to=jistone@redhat.com \
--cc=agentzh@gmail.com \
--cc=dsmith@redhat.com \
--cc=systemtap@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).