[PATCH] D152947: [DebugInfo] Change DWARFDebugAbbrev initialization

[Alex Langford via Phabricator via llvm-commits]

bulbazord added a comment.

In D152947#4429207 <https://reviews.llvm.org/D152947#4429207>, @dblaikie wrote:

>> If you want to iterate over one, presumably you wanted to actually parse the whole thing (at least that's what the current behavior is. We could expose a lazy version of the iterator that doesn't enforce this though).
>
> Not necessarily - using lazy fallible iterators might be suitable: https://llvm.org/docs/ProgrammersManual.html#building-fallible-iterators-and-iterator-ranges - maybe someone's searching through the list until they find something of interest and then want to stop. That, I think, is the direction @lhames 
> was going in - that whatever you did, you only got as much as you needed/didn't parse more - because maybe something later is corrupted (or just inefficient to parse) but it shouldn't stop you from seeing something earlier in a dumping tool, for instance.
>
>> There is still `DWARFDebugAbbrev::getAbbreviationDeclarationSet` which will get you just one set without parsing the entire section (and will not have the same assertion so that we can be lazy). Further up you said you wanted to avoid parsing more than just one `Decl` in a `DeclSet`, and I would assume that is the function that you would want to make "lazy" -- Presumably you know what the `CUAbbrOffset` would be from the `CU` header (or the index in the DWP case). It would be a matter of adding a lazy variant of this method which only parses the AbbreviationDeclarations that you ask it to (but still does error checking as needed). If it makes sense to be completely lazy, we can remove the support for being eager entirely. I just want us to be able to go fast and to handle errors instead of dropping malformed DWARF on the floor.
>>
>> This is roughly how I imagined it working (which is why I feel our goals are not opposed). What do you think?
>
> Yeah, I don't think it gets too much in the way - as you say, can still get one specific set, and can still add laziness there. Though maybe it's worth considering lazy iteration, not for my particular need/situation, but in general - for llvm-dwarfdump to be able to dump as much as it can, rather than failing on the last abbrev set and then not dumping the previous ones, for instance.

I'll take a look at the fallible iterator link you gave me and see what it would look like to implement that. I don't mind doing that if it makes the most sense in terms of usability/performance. Thanks for sharing that!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152947