https://sourceware.org/bugzilla/show_bug.cgi?id=30150
Nick Clifton <nickc at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|ASSIGNED |RESOLVED
--- Comment #29 from Nick Clifton <nickc at redhat dot com> ---
Hi Lev,
(In reply to Lev Veyde from comment #21)
> It seems to also depend on a tool.
Not really. All of the addr2line tools - except the patched binutils version -
are basically saying the same thing: there is no source code location
associated with the __SCT__x86_pmu_handle_irq symbol. I would argue that these
tools are wrong because they have only processed the DWARF information in the
.debug_info section and ignored the information in the .debug_line section.
The patched addr2line however does process both sections and it is saying that
the symbols is defined in paravirt.h:10. This is clearly wrong, *but* the
argument I was making in comment 20 is that it is not addr2line making a
mistake, but rather that the DWARF debug info inside vmlinux is wrong. (Not
corrupt per se, just generated incorrectly).
If you use other tools to look at the DWARF information, (readelf in the case
of comment #20, but I am pretty sure that you would get the same results if you
used GDB or some other consumer), it clearly shows that address
0xffffffff81c00290 is associated with line 10 of paravirt.h.
So - there is a second bug - probably in gcc, but possibly in the assembler or
linker - that is responsible for generating bad DWARF information. I suspect
that it is related to the use of inline assembler, possibly compounded by the
fact that header files and macros are involved. I would therefore ask that you
file a bug report with the gcc folks, explaining the situation. They can take
a look at it, and if they then point the finger back at the binutils, you can
open a new PR.
In the meantime though, I am going to close this PR, since the original bug -
inconsistent output from addr2line - has now been fixed. If you are unhappy
with this decision however, please feel free to reopen the PR.
Cheers
Nick
--
You are receiving this mail because:
You are on the CC list for the bug.
