The following simple test case shows a problem with inlined code in addr2line
(running on x86_64/Linux):
$ cat foo.cc
#include <stdio.h>
void __attribute__((always_inline)) bar() {
printf ("Hello World\n"); // line 4
}
void __attribute__((always_inline)) foo() {
bar();
bar();
}
int main() {
foo(); // line 13
return 0; // line 14
}
$ g++ -g -o foo foo.cc
$ objdump -d foo
...
00000000004005b2 <main>:
4005b2: 55 push %rbp
4005b3: 48 89 e5 mov %rsp,%rbp
4005b6: bf c8 06 40 00 mov $0x4006c8,%edi
4005bb: e8 d8 fe ff ff callq 400498 <p...@plt>
4005c0: bf c8 06 40 00 mov $0x4006c8,%edi
4005c5: e8 ce fe ff ff callq 400498 <p...@plt>
4005ca: b8 00 00 00 00 mov $0x0,%eax
4005cf: c9 leaveq
4005d0: c3 retq
...
$ readelf -wL foo
...
CU: foo.cc:
File name Line number Starting address
foo.cc 3 0x400588
foo.cc 4 0x40058c
foo.cc 5 0x400596
foo.cc 7 0x400598
foo.cc 4 0x40059c
foo.cc 10 0x4005b0
foo.cc 12 0x4005b2
foo.cc 4 0x4005b6
foo.cc 14 0x4005ca
foo.cc 15 0x4005cf
...
$ addr2line -e foo 0x4005c5
.../foo.cc:14
The call at 0x4005c5 is inlined from bar (via foo), and should be shown at line
4, but a test for line table rows that span functions in bfd/dwarf2.c is getting
in the way and forcing lookup_address_in_line_info_table to return the line
number from the next row (line 14 starting at pc 0x4005ca).
--
Summary: addr2line gives wrong line number for inlined code
Product: binutils
Version: 2.21 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: binutils
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: ccoutant at google dot com
CC: bug-binutils at gnu dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://sourceware.org/bugzilla/show_bug.cgi?id=10654
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
