[PATCH] D82838: Parse section ranges when verifying DWARF so we can exclude addresses that should have been stripped from DWARF.

[James Henderson via Phabricator via llvm-commits]

jhenderson added a comment.

In D82838#2123649 <https://reviews.llvm.org/D82838#2123649>, @clayborg wrote:

> In D82838#2122054 <https://reviews.llvm.org/D82838#2122054>, @jhenderson wrote:
>
> > I'm probably not best-placed to review this, as I haven't really used the verifier in practice, partly because of the exact problem this is trying to solve. In principle, I quite like not needing to use specific tombstone values here, but I wonder whether a "dead" range that isn't a tombstone value should itself be a verification failure, regardless of where it ends up?
>
>
> Can you give an example of what you are saying above? We can easily ignore tombstone values (-1, -2) in addition to what we are doing here. Zero is more problematic and more common from what I have seen, and that is what this patch really helps weed out. At address zero in a ELF file is right at the ELF header, so not many shared libraries actually have functions with a virtual address of zero from what I have seen.


I mean a range that isn't referenced by any function/data in the final output. For example, if I had the range [0x20, 0x30) in my .debug_ranges, but that range is outside the assigned addresses for the program (which might be, say [0x4000, 0x5000) and [0x10000, 0x20000), could it be a failure? There's no overlapping involved, but the range isn't useful and indicates something might have gone wrong.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82838