bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug binutils/30150] addr2line returns wrong results after several thous


From: nickc at redhat dot com
Subject: [Bug binutils/30150] addr2line returns wrong results after several thousands of requests in pipe mode
Date: Wed, 22 Feb 2023 11:35:03 +0000

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

Nick Clifton <nickc at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-02-22
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #16 from Nick Clifton <nickc at redhat dot com> ---
I have found a simpler reproducer for the problem, assuming that a copy of
vmlinux can be obtained:

  % addr2line -fipae vmlinux 0xffffffff82e21f2d 0xffffffff82e21f38
0xffffffff82e21f2d

  0xffffffff82e21f2d: int3_magic at alternative.c:?
  0xffffffff82e21f38: debug_alt at
/tmp/linux-5.15.92/linux-5.15.92/arch/x86/kernel/alternative.c:43
  0xffffffff82e21f2d: int3_magic at
/tmp/linux-5.15.92/linux-5.15.92/arch/x86/kernel/alternative.c:29

Note how the second decoding of the 0xffffffff82e21f2d address produces a
different result from the first.  Presumably this is because the second
decoding is using the line table that was read in whilst resolving the
0xffffffff82e21f38 address.

Sadly eu-addr2line gives consistent results:

  % eu-addr2line -f -i -a --pretty-print -e vmlinux \
      0xffffffff82e21f2d 0xffffffff82e21f38 0xffffffff82e21f2d

  0xffffffff82e21f2d: int3_magic at ??:0
  0xffffffff82e21f38: debug_alt at
/tmp/linux-5.15.92/linux-5.15.92/arch/x86/kernel/alternative.c:43:1
  0xffffffff82e21f2d: int3_magic at ??:0

I am not convinced however that either tool is correct in saying that the
filename and line number are not provided by the DWARF info.  The problem I
think is that the 0xffffffff82e21f2d address appears in two different line info
table.  The first, starting at offset 0xa0b9e into the .debug_line section puts
the address right at the very end of a sequence.  The second table, at offset
0xa1646, puts the address right at the start of a sequence.

Anyway, more investigation is needed...

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]