Re: Accessing user-space global variables in timer.profile?

[Josh Stone <jistone at redhat dot 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?