In a previous refactoring patch, Adrian didn't find this loop particularly readable, although admitted it was like that when I found it. :-)
I've tried renaming a variable and breaking up a condition, hopefully this will be clearer. I am very open to other ideas.
Details
- Reviewers
aprantl
Diff Detail
Event Timeline
Thanks!
llvm/lib/DebugInfo/DWARF/DWARFUnit.cpp | ||
---|---|---|
103 | Is there a comment that could explain which case is being checked for here? |
llvm/lib/DebugInfo/DWARF/DWARFUnit.cpp | ||
---|---|---|
103 | Well, there's the comment above the initialization of InsertPt. I don't think the original loop (pre-r338628) was doing what I thought it was doing. Prior to r313659, the loop was generating a unique_ptr for each unit in the section. In r313659, @dblaikie wanted to avoid parsing DWO units up front if possible, and have the get-unit-by-offset do them on-demand. But then here we need to parse all units. I *think* the intent was to skip units that had already been found lazily, and fill in the rest. But the r313659 version of the loop doesn't actually do that. It can successfully skip the offset=0 unit, if it is already present, but then it will generate a second vector entry for the next unit even if it's already present. I'll have to devise a unittest to prove this, though. I suspect that in addition to the ++InsertPt we also need to do a Offset = getNextUnitOffset of some kind. |
I'm abandoning this minor tweak as I am convinced that there is something more fundamentally wrong here.
llvm-dwarfdump doesn't call the right API sequence to show the bug; it requires a DWP, looking up a specific unit by hash via the DWP index, and then scanning all the units. I can envision how to do a unittest for that, but the unittest infrastructure doesn't currently support building a DWP. I can't take the time right now to address this, but I'll keep it on The List.
Is there a comment that could explain which case is being checked for here?