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.
