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

[Milian Wolff]

On Monday 02 June 2014 10:01:02 Arun Sharma wrote:
> On Mon, Jun 2, 2014 at 9:40 AM, Milian Wolff <address@hidden> wrote:
> > So... what now?
> >
> >_ULx86_64_tdep_trace: frame va 400d28 type 0 last 0 cfa rsp+0 rbp @ cfa-1
> >rsp @ cfa-1
> >
> >_ULx86_64_tdep_trace: new cfa 0x7fffb98a3820 rip 0x400d28 rsp
> >0x7fffb98a3820 rbp 0x0
> It looks like the fast unwind path found RBP=0, but f->last_frame is
> computed based on the return value of unw_step().
> Does this improve the situation?
> 
> --- a/src/x86_64/Gtrace.c
> +++ b/src/x86_64/Gtrace.c
> @@ -254,7 +254,7 @@ trace_init_addr (unw_tdep_frame_t *f,
>       common for the outermost frame (CRT stuff) on many systems.
>       This avoids failing trace in very common circumstances; failing
>       to unw_step() loop wouldn't produce any better result. */
> -  if (ret == 0)
> +  if ((ret == 0) || !rbp)
>      f->last_frame = -1;

Yes, that helps indeed. But I still have the frame above __libc_start_main in 
my backtraces. Is that "OK"? 

-- 
Milian Wolff
address@hidden
http://milianw.de