[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