[PATCH] D137139: [DWARF] Fix handling of .debug_aranges with -g1

Tue Nov 1 13:48:03 PDT 2022

clayborg added a comment.

In D137139#3900042 <https://reviews.llvm.org/D137139#3900042>, @ayermolo wrote:

> In D137139#3899179 <https://reviews.llvm.org/D137139#3899179>, @dblaikie wrote:
>
>> This is the sort of thing I kind of wanted to avoid when we were talking about adding the aranges verifier - fixing bugs in aranges when instead we should be fixing bugs in consumers to not depend on aranges.
>>
>> But anyway - if you really want/need aranges, perhaps a deeper fix would be good? We could emit aranges as CU ranges + data ranges instead of keeping an entirely separate list that can get out of sync? (& while we're at it, probably move the data ranges to the CU - rather than having to map them back from another independent data structure in DwarfDebug?)
>
> I totally agree... Trying to see if we can migrate internal tool from using aranges. Although considering this is a bit of a "special case" with -g1, might be OK just let it be for that tool.
>
> You have a good point. @clayborg can we just change lldb to ignore this section?

This is the first time I have been aware that .debug_aranges was so unreliable when we identified the root cause of this issue. I am totally fine and I will modify LLDB to ignore this section when it can. If we have valid indexes like .debug_names though, it would be a shame, if each compile unit doesn't have a DW_AT_ranges, to have to manually index the DWARF just to figure out the aranges for a compile unit, so I might let LLDB rely on this section if it is available, but only if the compile unit has no valid ranges.

We can modify every individual tool to work around the compiler producing a .debug_aranges section that doesn't do its job. That is certainly one way to fix this issue. I am also fine with giving up on .debug_aranges. In fact we should remove it completely from the compiler, as it isn't producing a section that any tool can rely on. Why are we even making it if we aren't going to do it right? And what is the with definition of doing it right, I think we have seen there are differences between what gcc and clang will produce. Part of this is the DWARF spec not . So yes I am fine with removing this section being used at all in LLDB. That still doesn't mean all of the other tools currently relying on it are going to work. So lets just stop the compiler from producing it all together, then no tools have to be modified so just magically know this section isn't reliable.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137139