This constructor allows us to create a new DWARFDataExtractor which will
only present a subrange of an entire debug section. Since debug sections
typically consist of multiple contributions, it is expected that one
will create a new data extractor for each contribution in order to
avoid unexpectedly running off into the next one.
This is very useful for unifying the flows for detecting parse errors.
Without it, the code needs to consider two very different scenarios:
- If there is another contribution after the current one, the DataExtractor functions will just start reading from there. This is detectable by comparing the current offset against the known end-of-contribution offset.
- If this is the last contribution, the data extractor will just start returning zeroes (or other default values). This situation can *not* be detected by checking the parsing offset, as this will not be advanced in case of errors.
Using a truncated data extractor simplifies the code (and reduces
cognitive load) by making these two cases behave identically -- a
running off the end of a contribution will _always_ produce an EOF error
(if one uses error-aware parsing methods) or return default values.
I wonder if this should be more generic than the DWARFDataExtractor class, i.e. be in DataExtractor? The concept of limiting length to a specified amount is hardly DWARF specific - ELF sections, for example, sometimes need parsing and have a limited length.
Preumably of course, we'd still want this constructor, but it would just forward to the base class one.