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

[Arun Sharma]

That's expected. For eg these unit tests do it too:

./tests/Ltest-bt v
./tests/Ltest-trace v

do it too.

 -Arun


On Mon, Jun 2, 2014 at 11:41 AM, Milian Wolff <address@hidden> wrote:
> 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