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

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

In D137139#4083504 <https://reviews.llvm.org/D137139#4083504>, @clayborg wrote:

> In D137139#3905859 <https://reviews.llvm.org/D137139#3905859>, @dblaikie wrote:
>
>> In D137139#3900161 <https://reviews.llvm.org/D137139#3900161>, @clayborg wrote:
>>
>>> 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.
>>
>> I agree in the abstract, but are there any producers you know of that don't produce CU ranges (& also do produce aranges) that this would be intended to support?
>
> I don't try to guess what compilers people will use and then feed to LLDB. I just know I have seen it all over the years. Any even if we fix current tools to produce new and better output that is well suited to the debugger, we still need to be able to load anything we are given from the past.

I think it'd be unfortunate to retain support for scenarios we have no evidence of - and in this particular case it'd just be worse performance to ignore aranges in the absence of CU ranges, not outright unsupported.

>>> 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.
>>
>> I'd expect a lot of folks are "getting by" with what it is today and removing it entirely would be a regression for them. Perhaps they are having problems they don't realize - or perhaps it's "good enough" in that the bugs don't hurt them too much, or maybe don't hurt them at all (if they never use -gmlt + -garanges, for instance, maybe that's OK). Maybe we could thread the needle and remove aranges for gmlt, since gmlt is so focussed on debug info size, that might be worthwhile & anyone who comes complaining that their tool that relied on aranges is broken or slow we can say "well, the aranges in that case weren't correct anyway, so we've helped you, really".
>>
>> Maybe that's a step along the deprecation/removal of aranges.
>
> By "gmlt" you mean "-g1"?

Yep.

> LLDB is fine if this section is not here, so removing it anytime we can get away with it is fine.
>
> The main issue is if we produce it, it should be reliable IMHO. AS you say, many people are relying on it, so anything we can do to fix it so that it is as correct as possible is a good thing.

That's my suggestion, though - one way we could address the bug with -g1+-garanges is to not support that combination/reject it/not emit aranges under -g1.

But if you've really got tools that ignore CU ranges that are significantly harder to change than fixing clang/llvm here - I guess we can fix llvm... But I'd /really/ encourage folks to push towards removing dependence on aranges whenever possible/practical.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137139