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 m...@milianw.de http://milianw.de