[Dwarf-Discuss] Fission + cross-CU references (ref_addr)

Robinson, Paul paul.robinson at sony.com
Thu May 4 14:26:11 PDT 2017


 In a split-DWARF scenario producing multiple CUs, it's clear that each split-full unit in the .dwo file would need a corresponding skeleton unit in the .o file,
Eric was tossing around an idea that would diverge from that - having a single skeleton for the whole DWO file (where the DWO file would contain multiple CUs - though the specifics there we hadn't hashed out - maybe every CU having the same DWO ID or the like), which could reduce the size of the debug info in object files in these situations. (LLVM produces a single debug_addr/debug_ranges/etc in Fission anyway - so every CU in a fission object file would include the same addr_base, ranges_base, the same abbrev offset, etc anyway)

Skeleton units are pretty small; it's a 20-byte header, plus values for the compile_unit DIE, which is spec'd to have no children.  I would not be concerned about space there.  And having unique DWO IDs per unit seems pretty useful.

Wrinkle 1: I think binutils DWP currently drops duplicate units (units with the same DWO ID). With this change, that wouldn't be possible - or at least all the /bytes/ of the DWO would have to be imported regardless, and in a contiguous chunk, so that cross-CU references would resolve correctly (if you had a DWO with 3 CUs in it, the middle of which turned out to be duplicate & was dropped, then the offset from a DIE in CU 1 to a DIE in CU 3 (now 2) would be broken). I think that's probably OK - such a DWP can only have one entry in the cu_index for that signature - but it can't drop the bytes anymore... *shrug*

That's true, each .debug_info section that had at least one retained split-full unit would have to be brought in completely.

Wrinkle 2: Type units go in the debug_info section, but you really do want to be able to drop duplicate type units when creating a DWP (that being the point of type units). So maybe require that DWO files have all the CUs first, then the TUs? and the INFO_FILE range only applies to the range over the CUs? This hurts/walks back the unification of CUs and TUs by special casing, unfortunately... - other ideas?

In non-split DWARF, type units are spec'd to have their own object-file section contributions, separate from the compile unit(s); that's what lets type units have a COMDAT key and be uniqued by the linker, even though all those separate contributions have the same section name.  (In ELF, you have multiple section headers with the same section name.)  Surely the DWO file could be (is?) done the same way, with each type unit in its own contribution to the .debug_info section?  Then the packager can incorporate or drop each of those contributions independently.  Being separate .debug_info lumps, the CUs are already on their own, and this Wrinkle goes away.

--paulr

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20170504/0f1d075d/attachment-0001.htm>


More information about the Dwarf-Discuss mailing list