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. I tend to agree, though - what sort of uses do you have in mind?
A unique DWO ID per unit lets each DWO unit have a distinct entry in the index… saves the consumer the trouble of having to read the .debug_info section to find the units. If you want to require consumers to do more work, you can make DWO IDs be per-file instead of per-unit, and then there's no need for an INFO_FILE column because the INFO column would necessarily have to cover the entire .debug_info section from that file. 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 sort of an implementation detail though, isn't it? DWARF just talks about bytes in sections (type units go in the debug_types section (or, now, the debug_info section)) and, yeah, you can use comdat groups and separate chunks of debug_types sections to deduplicate them, but I don't think DWARF requires/speaks about that, does it? Actually DWARF 5 Appendix E does describe this; not as a required tactic, but a way to achieve the useful effect of deduplicating type units etc. So yes it was overstating the case to say they are _spec'd_ to have their own contributions, but that would be what a producer would normally do. 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? Funny story about that... Heh. Which way works better (types all together, or each in their own contribution) depends on whether your packager wants to deduplicate in a linker-like way, based on COMDATs, or in a purpose-built way, by looking at the type-unit signatures directly. DWARF doesn't say you have to do one or the other, which provides implementation flexibility to the toolchain. If your packager is willing to look through TUs for signatures and deduplicate that way, then you can stuff all the TUs into one section contribution and get better compression. Quality of Implementation, as we like to say. still there would need to be a special case where the TU's debug_info chunk would have an INFO_FILE contribution that represente the CU chunk. So a DWP tool would have to special case the info chunk that contained the CUs (& would have to require that there be only one if there are to be TU->CU references. I suppose if TU->CU references aren't supported I don't think TU->CU references are permitted. Certainly you could not have a v4 split TU referencing a CU, that would be impossible. (Without relocations, you can't use DW_FORM_ref_addr to point from .debug_types to .debug_info; and DW_FORM_ref_sig8 is only for references to other type units.) While you could engineer the possibility in v5, because type units have moved back into .debug_info and in principle you could arrange for DW_FORM_ref_addr to do that, I am morally certain there was no intent to allow that. --paulr
_______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
