dwfl_module_addrdie fails for binaries built with clang++

Milian Wolff mail@milianw.de
Thu May 4 16:47:00 GMT 2017


Hey all,

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:

~~~~~~~~~~~
$ cat test.cpp
#include <cmath>
#include <random>
#include <iostream>

using namespace std;

int main()
{
    uniform_real_distribution<double> uniform(-1E5, 1E5);
    default_random_engine engine;
    double s = 0;
    for (int i = 0; i < 10000000; ++i) {
        s += uniform(engine);
    }
    cout << "random sum: " << s << '\n';
    return 0;
}
$ clang++ -O2 -g test.cpp -o test --std=c++11
$ objdump -Sl test | grep random.h -A2
<snip>
  400a10:       48 89 f0                mov    %rsi,%rax
--
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.3.1/../../../../include/c++/6.3.1/
bits/random.h:1818
        operator()(_UniformRandomNumberGenerator& __urng,
                   const param_type& __p)
$ addr2line -e test -i 400a10
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.3.1/../../../../include/c++/6.3.1/
bits/random.h:143
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.3.1/../../../../include/c++/6.3.1/
bits/random.h:151
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.3.1/../../../../include/c++/6.3.1/
bits/random.h:332
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.3.1/../../../../include/c++/6.3.1/
bits/random.tcc:3332
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.3.1/../../../../include/c++/6.3.1/
bits/random.h:183
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.3.1/../../../../include/c++/6.3.1/
bits/random.h:1818
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.3.1/../../../../include/c++/6.3.1/
bits/random.h:1809
/tmp/test.cpp:13
$ eu-addr2line -e test -i 400a10
??:0
~~~~~~~~~~~~~~~~~~~~~

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

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
-- 
Milian Wolff
mail@milianw.de
http://milianw.de



More information about the Elfutils-devel mailing list