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

[Milian Wolff]

On Tuesday 03 June 2014 09:53:02 Arun Sharma wrote:
> 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.

I just noticed an issue with adding the simple !bdp check to Gtrace.c - it 
leads to an early cancellation of the backtraces when sections without debug 
symbols are encountered:

...
0x7f868820167a QMapData::node_create(QMapData::Node**, int, int) 
/usr/lib/libQtCore.so.4
0x7f86886ea740 ? /usr/lib/libkdecore.so.5
0x7f86886fa986 ? /usr/lib/libkdecore.so.5
0x7f86886fafc4 ? /usr/lib/libkdecore.so.5
0x7f86886e4320 ? /usr/lib/libkdecore.so.5
0x7f86886e4731 KConfig::KConfig(QString const&, QFlags<KConfig::OpenFlag>, 
char const*) /usr/lib/libkdecore.so.5
... more useful information here

becomes

...
0x7f868820167a QMapData::node_create(QMapData::Node**, int, int) 
/usr/lib/libQtCore.so.4

For my use-case this is unacceptable. Any idea what might be going on here? 
Any information you would like me to get you?

> > 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 :)

The code here is already in libunwind, no? But why does it not "hit" in my 
case? I.e. if unw_step would return 0, that should be chached properly by 
unw_backtrace and the slow-path should not occur afterwards - or am I missing 
something? 

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