https://sourceware.org/bugzilla/show_bug.cgi?id=24191
Cary Coutant <ccoutant at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Cary Coutant <ccoutant at gmail dot com> ---
Actually, I think it's ld.bfd that's wrong here.
Ideally, when we discard a code section, we would also discard its debug info.
But the debug info format doesn't easily support this, and it would be a major
undertaking to make the linker capable of parsing, editing, and rewriting the
debug info (and that would make the linker unbearably slow).
In lieu of that, when we have a reference from debug info to a discarded
section, we resolve it using a base address of 0. This is deliberate, and
the debugger is (or should be) aware of this, so that it can ignore the
orphaned debug info. For other references to the discarded section, we do
in fact resolve them to point to the kept copy, but for debug info, we
resolve to 0.
Imagine what would happen if two copies of a function were compiled with
different optimization levels (or other options that would affect the code
generation). The line number tables (as well as any range information for
nested blocks inside the function) would differ, and it would be incorrect
for the discarded copy's debug info to be resolved to the kept copy of the
function. If the debugger were to find the mismatched line table while
doing an address-to-source-line lookup, it would then get the wrong answer.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
