On Freitag, 5. Mai 2017 15:06:48 CEST Mark Wielaard wrote:
> Hi Milian,
> 
> On Thu, 2017-05-04 at 18:05 +0200, Milian Wolff wrote:
> > I noticed that elfutils fails to handle clang binaries when we want to
> > find a DIE for a certain address. I.e. dwfl_module_addrdie returns
> > nullptr, and eu- addr2line fails to resolve inlined frames.
> >
> > To reproduce this:
> >[...]
> >
> > This also affects us in our perfparser. Not being able to find a cudie
> > means not finding inlined frames nor file/line mappings, which is quite a
> > set-back.
> > 
> > I have noticed that backward-cpp contains a (partially) work-around for
> > this:
> > 
> > https://github.com/bombela/backward-cpp/blob/master/backward.hpp#L1216
> 
> O urgh how utterly broken (not backward-cpp, but the bogus DWARF clang
> generates). As that comment says:
> 
>         // Sadly clang does not generate the section .debug_aranges,
>         thus
>         // dwfl_module_addrdie will fail early. Clang doesn't either set
>         // the lowpc/highpc/range info for every compilation unit.
>         //
>         // So in order to save the world:
>         // for every compilation unit, we will iterate over every single
>         // DIEs. Normally functions should have a lowpc/highpc/range, which
>         // we will use to infer the compilation unit.
> 
>         // note that this is probably badly inefficient.
> 
> And indeed having to scan through every CU to find a matching function
> DIE is badly inefficient :{

But this code comment is relatively old. Are we sure it's really still the 
case?

> > Is this the right approach and also what the non-eu addr2line does? If so,
> > can that be added upstream too, such that dwfl_module_addrdie can be
> > relied on?
> > 
> > I've seen it on clang 3.6, 4 and 5. Neither passing -g3 nor
> > -gdwarf-aranges
> > helps.
> 
> Thanks for reporting this. I think this might be the same issue seen
> here: https://sourceware.org/bugzilla/show_bug.cgi?id=21247
> ... or at least it seems related. The function/address not found in that
> case also comes from a CU generated by clang. It does have a lowpc and
> ranges, but the lowpc looks bogus (zero) and the ranges don't seem to
> cover the function in question. So it seems even worse than your example
> where there are no lowpc/ranges. We cannot even trust them if they are
> there. Sigh.

So the situation is different from the comment in backward-cpp...

> I have to think about how to handle this. We clearly need something that
> just ignores the lowpc/highpc/ranges on CUs and parses every CU till the
> function/address DIE is found to know which CU and line_table to use.
> But that is so inefficient that I don't want to do that by default.

So, if this is really that bad - what are the binutils doing - does anyone 
know? Also, if it's really against all your expectations, shouldn't we report 
this upstream at clang and ask for input there? I can't believe they knowingly 
break their generated code in such a way. Rather, I believe it's either done 
unknowingly, or there is some alternative way to interpret the data that we 
are not aware of?

Cheers

-- 
Milian Wolff
mail@milianw.de
http://milianw.de