This is an archive of the discontinued LLVM Phabricator instance.

[WIP][DebugInfo] Lazily parse debug_loclist offsets
ClosedPublic

Authored by dblaikie on Aug 17 2020, 2:34 PM.

Details

Summary

Parsing DWARFv5 debug_loclist offsets when a CU is parsed is weighing
down memory usage of symbolizers that don't need to parse this data at
all. There's not much benefit to caching these anyway - since they are
O(1) lookup and reading once you know where the offset list starts (and
can do bounds checking with the offset list size too).

In general, I think it might be time to start paying down some of the
technical debt of loc/loclist/range/rnglist parsing to try to unify it a
bit more.

eg:

  • Currently DWARFUnit has: RangeSection, RangeSectionBase, LocSection, LocSectionBase, LocTable, RngListTable, LoclistTableHeader (be nice if these were all wrapped up in two variables - one for loclists, one for rnglists)
  • rnglists and loclists are handled differently (see: LoclistTableHeader, but no RnglistTableHeader)
  • maybe all these types could be less stateful - lazily parse what they need to, even reparsing rather than caching because it doesn't seem too expensive, for instance. (though admittedly so long as it's constantcost/overead per compilatiton that's probably adequate)
  • Maybe implementing and using a DWARFDataExtractor that can be sub-ranged (so we could slice it up to just the single contribution) - though maybe that's not so useful because loc/ranges need to refer to it by absolute, not contribution-relative mechanisms

Diff Detail

Event Timeline

dblaikie created this revision.Aug 17 2020, 2:34 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptAug 17 2020, 2:34 PM
dblaikie requested review of this revision.Aug 17 2020, 2:34 PM

This sounds perfectly reasonable to me. The offsets are present in memory already so there's no point in storing them in a vector as well.

dblaikie accepted this revision.Aug 18 2020, 10:11 AM

This sounds perfectly reasonable to me. The offsets are present in memory already so there's no point in storing them in a vector as well.

Thanks for taking a look! I'll take this as approval and commit soon.

This revision is now accepted and ready to land.Aug 18 2020, 10:11 AM
This revision was landed with ongoing or failed builds.Aug 18 2020, 10:50 AM
This revision was automatically updated to reflect the committed changes.

This sounds perfectly reasonable to me. The offsets are present in memory already so there's no point in storing them in a vector as well.

Thanks for taking a look! I'll take this as approval and commit soon.

The patch had a WIP label, so I was only looking/commenting on the high-level idea. But after looking at the implementation more closely, I think that looks good too.

This sounds perfectly reasonable to me. The offsets are present in memory already so there's no point in storing them in a vector as well.

Thanks for taking a look! I'll take this as approval and commit soon.

The patch had a WIP label, so I was only looking/commenting on the high-level idea. But after looking at the implementation more closely, I think that looks good too.

Right right - sorry about that. Realized after I committed it it still had that tag & totally understand it gave the wrong impression. I think when I wrote the commit message I was still thinking about it, but by the time I sent it for review, tested more things, etc, I was more comfortable with it & didn't think to change the message.

jankratochvil added inline comments.
llvm/include/llvm/DebugInfo/DWARF/DWARFListTable.h
116

That is going to be addressed in D98289.

dblaikie added inline comments.Mar 12 2021, 1:51 PM
llvm/include/llvm/DebugInfo/DWARF/DWARFListTable.h
116

Ah, thanks for the catch!