Re: [Libunwind-devel] Backtrace performance on x86-64 based on Dwarf info

[Arun Sharma]

On Tue, Jun 3, 2014 at 6:18 AM, Milian Wolff <address@hidden> 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