This is an archive of the discontinued LLVM Phabricator instance.

[DWARF v5][NFC] Refactor the implementation of DebugRnglists
ClosedPublic

Authored by wolfgangp on Apr 4 2018, 6:09 PM.

Details

Summary

The current implementation of DebugRnglists (essentially the handling of the DWARF v5 .debug_rnglists and .debug_rnglists.dwo sections) is geared towards dumping the section. To handle references from DIEs via the DW_AT_ranges attribute we need more flexibility, which is what this refactor is trying to do.

The following changes are in this patch:

  1. Parsing of rnglist tables is separated into parsing of headers/offsets and parsing (extracting) of individual rangelists. The previously monolithic extract() routine is broken into 3 parts: a) extraction of an individual rnglist entry, b) extraction of a rnglist (made up of multiple entries) and c) extraction of the entire table.

The idea is that the table headers and offsets are parsed when we first encounter the DW_AT_rnglist_base attribute in the CU DIE (or when we parse the CU DIE in split units). As we see DW_AT_ranges attributes in DIEs, we parse the rnglists referenced by them and enter them into a map (with section offsets as keys), where they can be looked up. The code for this will follow. This is just prep.

  1. We calculate the maximum encoding string length for dumping before we dump the table and not during parsing of the range lists. Only the dumper cares about this.

Not in this patch is an interface to extract a range list from a section offset and a way to convert a range list into a DWARFAddressRangesVector, which is what DWARFDie::getAddressRanges returns. These will be part of the next patch, which will implement the full functionality with tests.

Diff Detail

Repository
rL LLVM

Event Timeline

wolfgangp created this revision.Apr 4 2018, 6:09 PM
JDevlieghere accepted this revision.Apr 5 2018, 6:27 AM

LGTM

lib/DebugInfo/DWARF/DWARFDebugRnglists.cpp
168 ↗(On Diff #141095)

Maybe we should have a constructor for this?

This revision is now accepted and ready to land.Apr 5 2018, 6:27 AM
wolfgangp added inline comments.Apr 5 2018, 10:53 AM
lib/DebugInfo/DWARF/DWARFDebugRnglists.cpp
168 ↗(On Diff #141095)

I had a constructor in an earlier version (before this patch), but Dave suggested to get rid of it in favor of simple braced initializers. I don't have a strong opinion on this but it does seem to me that a constructor would add little value, given that it's really a very simple type, and the braced initializer does the same thing. I also don't anticipate this data structure to be created in lots of other places, where a constructor would provide more safety.

If you don't mind I'd like to keep it that way unless you feel strongly about it.

dblaikie added inline comments.Apr 5 2018, 12:40 PM
include/llvm/DebugInfo/DWARF/DWARFDebugRnglists.h
40 ↗(On Diff #141095)

Maybe this (& DWARFDebugRngList::extract) should be a factory function (either static member or free function) returning ErrorOr<RangeListEntry> (and ErrorOr<DWARFDebugRngList>) - encapsulation doesn't seem to important here - a vector of structs seems like a pretty fine data structure for this purpose/no need to wrap it up in public/private things, etc?

This revision was automatically updated to reflect the committed changes.