[PATCH] D136395: Add the ability to verify the .debug_aranges section.

Alexander Yermolovich via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Oct 24 10:33:01 PDT 2022


ayermolo added a comment.

In D136395#3875846 <https://reviews.llvm.org/D136395#3875846>, @dblaikie wrote:

> In D136395#3875783 <https://reviews.llvm.org/D136395#3875783>, @ayermolo wrote:
>
>> In D136395#3873072 <https://reviews.llvm.org/D136395#3873072>, @dblaikie wrote:
>>
>>> If possible, I'd rather not add this - I think .debug_aranges should be removed (it's already been off-by-default for a decade in Clang) in favor of using CU-level address ranges. They're cheap-enough to parse that it doesn't substantially change the performance of tools so far as I'm aware and they save space by not duplicating the address range information in two places.
>>>
>>> Adding a verifier feels like endorsing/encouraging/maintaining `.debug_aranges` which seems like the wrong direction we should be going.
>>
>> Can you elaborate on why they should be removed. Is it because of the aforementioned duplication of information, or are there other reasons also?
>
> Yeah, basically only that - they're redundant, and maintaining different paths is a burden (verifying them, fixing bugs in them, having tools that either consume one or the other or both, etc) - having a single way to represent things would be better for the DWARF ecosystem of consumers and producers.
>
> (also aranges haven't been updated to benefit from the more compact/fewer-relocation-using encoding of .debug_rnglists introduced in DWARFv5 - so it's bigger/less efficient now as well)

I see. That makes sense, but unfortunately that option still exists and is being used. We hit an issue where there is inconsistency that I am looking into right now on llvm side. Thus this patch on verify side. I am also trying to follow up internally if we can just stop using this section.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136395



More information about the llvm-commits mailing list