Re: dwfl_module_addrdie fails for binaries built with clang++

[Mark Wielaard <mark at klomp dot org>]

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

> 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.

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.

Cheers,

Mark