[llvm-dev] Fragmented DWARF

[James Henderson via llvm-dev]

On Mon, 9 Nov 2020 at 15:37, Alexey Lapshin <avl.lapshin at gmail.com> wrote:

> I mean the run-time memory usage of DebugInfoDWARF library.
> Currently, when Object file is loaded and DWARFContext class is created
> the DWARFContext references section data from object::ObjectFile:
>
> DWARFContext(std::unique_ptr<const DWARFObject> DObj,..)
>
> DWARFObjInMemory(const object::ObjectFile &Obj, ...)
>
> class DWARFObjInMemory {
>   const DWARFSection &getLocSection() const;
>   const DWARFSection &getLoclistsSection() const;
>   StringRef getArangesSection() const;
>   const DWARFSection &getFrameSection() const;
>   const DWARFSection &getEHFrameSection() const;
>   const DWARFSection &getLineSection() const;
>   StringRef getLineStrSection() const;
> }
>
> class DWARFUnit {
>   DWARFContext &Context;
>   /// Section containing this DWARFUnit.
>   const DWARFSection &InfoSection;
> }
>
> struct DWARFSection {
>   StringRef Data;
> };
>
> DWARFSection references data that are loaded by Object file.
> DWARFSection is assumed to be a monolithic piece of data.
> There is a code using these data assuming random access:
>
> StringRef LineData = OrigDwarf.getDWARFObj().getLineSection().Data;
> LineData.slice(*StmtList + 4, PrologueEnd)
> ...
> StringRef FrameData = OrigDwarf.getDWARFObj().getFrameSection().Data;
> FrameData.substr(EntryOffset, InitialLength + 4)
> ...
> InputSec = Dwarf.getDWARFObj().getLocSection();
> InputSec.Data.substr(Offset, Length);
> ...
> DWARFDataExtractor RangesData(Context.getDWARFObj(), *RangeSection,
>                               isLittleEndian, getAddressByteSize());
> uint64_t ActualRangeListOffset = RangeSectionBase + RangeListOffset;
> RangeList.extract(RangesData, &ActualRangeListOffset);
>
>
> i.e. It is possible to access random piece of DWARFSection.
>
> If object::ObjectFile would contain fragmented sections then
> we need a solution of how that could work.
>
> One possibility is to create a glued copy of fragmented data and pass it
> to the DWARFObj.
> But that would require to load all original debug info sections twice
> (fragmented sections inside Objectfile and glued sections inside DWARFObj).
>
> Another possibility is to rewrite DebugInfoDWARF/DWARFSection to avoid
> random access to the data(if that is possible).
>
The only consumers who would have to do something I haven't measured would
be tools like llvm-dwarfdump. I think this is easily solved by modifying
DWARFObjInMemory to store a list of sections containing data per section
(rather than a single section), and then providing a DWARFDataExtractor
constructor overload that takes such a list. The DWARFDataExtractor could
then do the jumping transparently. I wouldn't anticipate the memory usage
being a real problem - the biggest cost would be the overhead of N
DWARFSection instances (i.e. approximately N pointers + N sizes), where N
is the number of these fragmented sections. This certainly could be
significant, but I suspect that compared to the cost of linking the output
it wouldn't be a problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201110/9e061ca0/attachment.html>