Hello, I'm trying to improve Linux perf report by adding inliner information to the callstacks it reports, to make the output more easily interpretable when looking at complicated C++ applications.
I have a proof of concept locally using bfd_find_inliner_info, but have noticed the following seemingly broken behavior: Input file: ~~~~~~~~~test.cpp~~~~~~~ #include <cstdlib> #include <iostream> #include <complex> int main(int argc, char** argv) { double a = 0; double b = 0; if (argc > 1) a = atof(argv[1]); if (argc > 2) b = atof(argv[2]); auto c = std::complex<double>(a, b); std::cout << std::abs(c) << std::endl; } ~~~~~~~~~~~~~~~~~~~~~~~~ I build it with: ~~~~~~~~~building~~~~~~~ $ g++ -g -O2 -o test test.cpp ~~~~~~~~~~~~~~~~~~~~~~~~ Then I get a "good" backtrace using GDB: ~~~~~~~~~gdb~~~~~~~~~~~~ $ gdb ./test (gdb) break hypot Function "hypot" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (hypot) pending. (gdb) run Starting program: /tmp/test Breakpoint 1, 0x00007ffff776e910 in hypot () from /usr/lib/libm.so.6 (gdb) bt #0 0x00007ffff776e910 in hypot () from /usr/lib/libm.so.6 #1 0x00000000004007f4 in std::__complex_abs (__z=<optimized out>) at /usr/ include/c++/6.2.1/complex:589 #2 std::abs<double> (__z=<synthetic pointer>) at /usr/include/c++/6.2.1/ complex:597 #3 main (argc=<optimized out>, argv=<optimized out>) at test.cpp:14 ~~~~~~~~~~~~~~~~~~~~~~~~ Note what inliners it reports for the address 0x00000000004007f4. Let's try bfd_find_inliner_info via eu-addr2line -i: ~~~~~~~~~eu-addr2line~~~ eu-addr2line -i -a 0x00000000004007f4 -e ./test 0x00000000004007f4 /usr/include/c++/6.2.1/ostream:221 /tmp/test.cpp:14 ~~~~~~~~~~~~~~~~~~~~~~~~ This is wrong and seems to be off-by-one: ~~~~~~~~~eu-addr2line~~~ eu-addr2line -i -a 0x00000000004007f3 -e ./test 0x00000000004007f3 /usr/include/c++/6.2.1/complex:589 /usr/include/c++/6.2.1/complex:597 /tmp/test.cpp:14 ~~~~~~~~~~~~~~~~~~~~~~~~ Can someone with more knowledge in this area sched some light on what is going on here please? Is it a bug, or is this fuzzy behavior and GDB happens to be better at guessing the "right" thing? Some system info: linux 4.7.2-1-ARCH eu-addr2line 0.167 g++ 6.2.1 gdb 7.11.1 Thanks -- Milian Wolff m...@milianw.de http://milianw.de _______________________________________________ elfutils-devel mailing list -- elfutils-devel@lists.fedorahosted.org To unsubscribe send an email to elfutils-devel-le...@lists.fedorahosted.org