This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug translator/17966] @defined always returns true in return probes


https://sourceware.org/bugzilla/show_bug.cgi?id=17966

Josh Stone <jistone at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|systemtap at sourceware dot org    |jistone at redhat dot com

--- Comment #1 from Josh Stone <jistone at redhat dot com> ---
I did suggest that's what going on, but it appears more subtle when I look
closer.

If I try process("bash").function("main").return, it gets this error.  I don't
have debuginfo installed for bash.

If I try process("stap").function("main").return, it works as expected.  I do
have debuginfo for my local stap.

In dwarf_var_expanding_visitor::visit_target_symbol, we have:

      // Everything else (pretty-printed vars, and context vars) require a
      // scope_die in which to search for them. If we don't have that, just
      // leave it unresolved; we'll produce an error later on.
      if (null_die(scope_die))
        {
          provide(e);
          return;
        }

The case without debuginfo will hit this and return without error, leaving
@defined undecided for the moment.  The case with debuginfo will get past this,
set an error on e directly, and cause @defined to be 0 right away, as desired.

So I need to figure out why the delayed case doesn't fix @defined later...

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]