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

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

In D136395#3880008 <https://reviews.llvm.org/D136395#3880008>, @ayermolo wrote:

> 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.

Could you provide more detail about this inconsistency?

(one issue I can say is that if you're comparing GCC and Clang `.debug_aranges` you'll see differences - Clang includes global variable addresses in the table and GCC does not)

> Thus this patch on verify side.

Has it discovered anything interesting so far during development?

> I am also trying to follow up internally if we can just stop using this section.

Thanks!

In D136395#3880237 <https://reviews.llvm.org/D136395#3880237>, @probinson wrote:

> We (Sony) also have some tooling that relies on .debug_aranges; while I sympathize with wanting to get rid of it, and I've filed a ticket to update the relevant tooling, we're not there yet.
> Actually getting rid of .debug_aranges would probably deserve an RFC to raise the visibility, because there are clearly tools in various odd places that expect it to be there.  But if that process is not imminent, I'm not opposed to introducing verification to make sure we get it right.

Yeah, this review isn't getting rid of .debug_aranges and I agree, when we get to that point an RFC would be suitable.

For now I'm just of the opinion that the feature may not be worth certain amounts of work, code review, design, etc, if we can help it. but happy to discuss what sort of value this might provide.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136395