[PATCH] D59553: [WIP][LLD][ELF][DebugInfo] Use predefined value to mark debug address ranges pointing to deleted code.
David Blaikie via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Jun 9 18:48:22 PDT 2020
dblaikie added a comment.
In D59553#2083674 <https://reviews.llvm.org/D59553#2083674>, @MaskRay wrote:
> > (summary-ish: comdat functions that are optimized differently: subprograms must not refer to the differently optimized version
> > comdat functions that are optimized identically: multiple subprograms could point to the same code, but there's probably little benefit/reason to do so
> > identical unrelated functions: there's value in multiple subprograms pointing to the same code)
>
> Resolving a (relocation referencing a symbol defined in a discarded COMDAT group) to the tombstone value may be more troublesome.
>
> clang -c -ffunction-sections a.cc # no debug info
> clang -c -ffunction-sections -g b.cc
>
>
> Assuming a.cc & b.cc define the same function, should the linker resolve relocations in b.o(.debug_info) to the tombstone value? Maybe not because we'll lose all debugging information.
> If both a.o & b.o have debugging information, it may be reasonable to resolve relocations in b.o(.debug_info) to the tombstone value.
if it comes to that, yeah, it would be nice-to-have if one debug info copy got the non-tombstone value, but I wouldn't stress about that - it's a pretty narrow case, and would only apply with a partial-debug build (we have a lot of debug info optimizations that are on-by-default (except for lldb) that assume the whole program is built with debug info).
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D59553/new/
https://reviews.llvm.org/D59553
More information about the llvm-commits
mailing list