From mboxrd@z Thu Jan  1 00:00:00 1970
Content-Type: multipart/mixed; boundary="===============5573515189405926250=="
MIME-Version: 1.0
From: Milian Wolff <mail@milianw.de>
To: elfutils-devel@lists.fedorahosted.org
Subject: bfd_find_inliner_info reports different (wrong) information compared
 to GDB - off-by-one?
Date: Wed, 05 Oct 2016 17:45:54 +0200
Message-ID: <1861829.c730vLF16V@milian-kdab2>

--===============5573515189405926250==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

Hello,

I'm trying to improve Linux perf report by adding inliner information to th=
e =

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 =3D 0;
    double b =3D 0;
    if (argc > 1)
        a =3D atof(argv[1]);
    if (argc > 2)
        b =3D atof(argv[2]);
    auto c =3D 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=3D<optimized out>) at /us=
r/
include/c++/6.2.1/complex:589
#2  std::abs<double> (__z=3D<synthetic pointer>) at /usr/include/c++/6.2.1/
complex:597
#3  main (argc=3D<optimized out>, argv=3D<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 go=
ing =

on here please? Is it a bug, or is this fuzzy behavior and GDB happens to b=
e =

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