[PATCH] D81784: [ELF] Resolve relocations in .debug_* referencing (discarded symbols or ICF folded section symbols) to tombstone values

Mon Jun 29 00:29:38 PDT 2020

jhenderson added a comment.

In D81784#2117592 <https://reviews.llvm.org/D81784#2117592>, @dblaikie wrote:

> I have mixed feelings about this - I assume any strategy for this would likely also trigger for the case I've seen more often, which is two inline function definitions that are identical and rather than one DW_TAG_subprogram getting to point to the final copy, both DW_TAG_subprograms in different CUs point to the final copy (if that copy is the same length, I think is the test in other linkers - but maybe it's if their contents are identical)?
>
> Is this a change in lld's behavior? Or has lld always resolved identical-but-deduplicated functions to only the one subprogram, or to all subprograms?

I haven't specifically looked at the other debug sections. I believe they previously contained duplicate addresses, but am not 100% sure. In most cases this is bad due to ambiguity reasons, I believe. In our downstream port, we patched to -1/-2 (except for .debug_line).

> Or is your workaround (the one you have in your fork) /only/ for the line table, but not for DW_AT_ranges on the CU or for the low_pc of the subprogram? That would seem pretty quirky - having addresses covered by the line table that aren't covered by the ranges of the CU? But also if it is applied to teh CU too, then you have CUs with overlapping ranges (@probinson I think expressed some concern about overlapping CUs being undesirable previously)

Our implementation specifically special-cases behaviour for .debug_line to be different to other debug sections, which used -1/-2 for the address references to de-duplicated code, so .debug_ranges for example didn't have overlapping ranges etc. I don't think it's that quirky - the debug line table is actually independent of other debug data and can usefully exist without .debug_info etc; it doesn't know anything about its corresponding CU (apart from some file paths). That all being said, it's been a fairly recent change in our downstream port. Before that, we just did what this patch does in .debug_line as well as other sections.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81784/new/

https://reviews.llvm.org/D81784