[PATCH] D60470: [DWARF] Change ambiguity resolution from smallest CUOffset to largest (LowPC, CUOffset)

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Apr 17 08:24:58 PDT 2019


dblaikie added a comment.

In D60470#1469679 <https://reviews.llvm.org/D60470#1469679>, @MaskRay wrote:

> > Ah, sorry, that's not the case I was interested in. I meant a case where two object files are linked together - one has debug info, one does not. They both have a comdat function. The non-debug info version is chosen (creating the [0, X) address range in the debug info from the other object).
>
> If the linker makes the comdat function without debug info (assuming the debug info is not in a comdat) prevailing, the one with debug info is discarded while its debug info is kept. This is essentially the same as the `--gc-sections` case.
>
> The compile unit with 0 `DW_AT_low_pc` is actually invalid because the addresses are incorrect. It should be ignored if it overlaps with a valid range when constructing aranges. This patch will do so.
>
> > If I understand it, this change is to the prioritization/resolution of ambiguities - but similar situations/bugs can arise when there is no ambiguity (because some code has no debug info - so it's not there to create an ambiguity). if I'm understanding/explaining correctly.
>
> Yes, it is related to the resolution of ambiguities. The old rule is to pick the CU with the smallest `E.CUOffset`; the new rule is to pick the CU with the largest `(E.LowPC, E.CUOffset)` pair.


What I'm trying to ask is - it sounds like this is about resolution of an ambiguity between the wrong answer (the zero-based entry due to a comdat function not being chosen, or a gc-section being GC'd - but where the address range, even zero based, overlaps with executable code) and the right one (the one with a non-zero low pc).

So what I'm asking is: what happens if the right one isn't there (because that code wasn't built with debug info) - would we still get the wrong answer?


Repository:
  rL LLVM

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

https://reviews.llvm.org/D60470





More information about the llvm-commits mailing list