On Tue, Jun 3, 2014 at 6:18 AM, Milian Wolff <[email protected]> wrote:
>
> To me that does not look like a failure :)
>
Yeah, I'll fix up the test too unless this breaks any of the stuff
Lassi may be aware of.
> Furthermore, while this patch fixes the unw_backtrace usage for me, shouldn't
> the same be done for the unw_step case? There, the last call to unw_step still
> triggers the slow-path which I mentioned in my original thread. How could we
> fix this? Where is the analogous check for last frame based on rbp in the
> code? And, if we'd fix it there, wouldn't then the patch to Gtrace.c be
> obsolete, as then we'd get ret == 0 already, no?
Here's the code that does the same thing in unw_step:
src/x86_64/Gstep.c:
if (!rbp)
{
/* Looks like we may have reached the end of the call-chain. */
rbp_loc = DWARF_NULL_LOC;
rsp_loc = DWARF_NULL_LOC;
rip_loc = DWARF_NULL_LOC;
}
...
if (DWARF_IS_NULL_LOC (c->dwarf.loc[RBP]))
{
ret = 0;
Debug (2, "NULL %%rbp loc, returning %d\n", ret);
return ret;
}
But anything can happen once you get into a weird combination of dwarf
based unwinding, frame chain based unwinding, heuristics and real
world complexity :)
-Arun
_______________________________________________
Libunwind-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/libunwind-devel
