This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug translator/17966] @defined always returns true in return probes
- From: "jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Thu, 12 Feb 2015 22:08:11 +0000
- Subject: [Bug translator/17966] @defined always returns true in return probes
- Auto-submitted: auto-generated
- References: <bug-17966-6586 at http dot sourceware dot org/bugzilla/>
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.