[Bug binutils/30150] addr2line returns wrong results after several thousands of requests in pipe mode

[nickc at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30150

--- Comment #20 from Nick Clifton <nickc at redhat dot com> ---
OK, so the patch works, but there is at least one more problem.  The source
locations are not always accurate.  For example:

  % addr2line -fiape vmlinux 0xffffffff81c00290
0xffffffff81c00290: __SCT__x86_pmu_handle_irq at
/tmp/linux-5.15.92/linux-5.15.92/./arch/x86/include/asm/paravirt.h:10

Which is wrong because the (assembler) function __SCT__x86_pmu_handle_irq is
actually defined in .../arch/x86/events/core.c using a macro defined in
.../arch/x86/include/asm/static_call.h.

However it appears that addr2line is not blame, as other tools produce the same
result:

  % readelf -wL vmlinux | grep -B1 0xffffffff81c00290
  File name         Line number    Starting address    View    Stmt
  paravirt.h        10             0xffffffff81c00290           x

  % eu-readelf --debug-dump=decodedline vmlinux | grep -B1 ffffffff81c00290
  ./arch/x86/include/asm/paravirt.h (mtime: 0, length: 0)
    10:0   S        0   0  0 0xffffffff81c00290 <__SCT__x86_pmu_handle_irq>

So presumably either bad line number information was produced when the vmlinux
binary was compiled, or the information was corrupted when the binary was
linked.

-- 
You are receiving this mail because:
You are on the CC list for the bug.