Using addr2line to display all inlined functions referenced by an address often fails with our code. The outermost function is marked as unknown, even though source and line information is available and objdump can be used to identify the function. For example: addr2line -C -f -i -e libpolicy_enforcement.so 0x12ffa7 Ternary_OR /home/brad/root/scorpius/main/src/common/include/fdt/ternary.hpp:121 ?? /home/brad/root/scorpius/main/src/policy/policy_enforcement/afl/afl_section.cpp: 619 Tracing the code, the problem seems to be in bfd/dwarf2.c:scan_unit_for_symbols. When the code goes through the func attributes, it does not handle the case where the function has a DW_AT_specification and points to a previous declaration for its name. This seems to occur frequently for nested functions. The following patch to dwarf2.c (based on binutils-2.20.51) fixes the issue for me: --- binutils-modified/bfd/dwarf2.c 2010-09-29 10:44:40.000000000 -0400 +++ binutils-2.20.51/bfd/dwarf2.c 2010-07-14 18:18:07.000000000 -0400 @@ -2115,10 +2115,6 @@ { switch (attr.name) { - case DW_AT_specification: - func->name = find_abstract_instance_name (unit, &attr); - break; - case DW_AT_call_file: func->caller_file = concat_filename (unit->line_table, attr.u.val); Now running the same command with the updated addr2line gives the following output: addr2line -C -f -i -e libpolicy_enforcement.so 0x12ffa7 Ternary_OR /home/brad/root/scorpius/main/src/common/include/fdt/ternary.hpp:121 AFL_Section::Compute_rule_filters(AFL_Environment&, AFL_Filter*&) /home/brad/root/scorpius/main/src/policy/policy_enforcement/afl/afl_section.cpp: 619
Hi Brad, The patch looks reasonable, but please could you supply a small test case that I could use to check it out ? (Plus then I can add the testcase to the binutils testsuite to make sure that this problem does not resurface in the future). Cheers Nick
Hmm... What would a small test case look like? I have an executable that exhibits this issue, but it is not small. Would you want a compiled object that exhibits this problem? Brad. On 10/27/2010 10:46 AM, nickc at redhat dot com wrote: > http://sourceware.org/bugzilla/show_bug.cgi?id=12073 > > Nick Clifton<nickc at redhat dot com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEW |WAITING > CC| |nickc at redhat dot com > > --- Comment #1 from Nick Clifton<nickc at redhat dot com> 2010-10-27 14:46:11 UTC --- > Hi Brad, > > The patch looks reasonable, but please could you supply a small test case > that I could use to check it out ? (Plus then I can add the testcase to the > binutils testsuite to make sure that this problem does not resurface in the > future). > > Cheers > Nick > >
Hi Brad, > What would a small test case look like? Ideally one or two simple assembler source files that can be turned into object files, linked together and then run through addr2line to reproduce the behaviour you described in your bug report. Failing that a couple of small C source files would work. > Would you want a compiled object that exhibits this problem? That would be my least favourite choice because they cannot be turned into a testcase in the testsuite. They would help checking that the fix works, but I would like to be able to make sure that the problem stays fixed in the future. Cheers Nick
This was fixed with commit 5d8e6b4d11a1.