On Tue, Feb 25, 2020 at 11:41 AM Pavel Labath <lab...@google.com> wrote:
> Yeah, this sounds tricky, but it is actually good timing, because I > was just about to start working on DWP v5 in lldb. I was hoping that > would be an easy ride, but it looks like things will get complicated. > > On Tue, 25 Feb 2020 at 18:53, David Blaikie <dblai...@gmail.com> wrote: > > > > (please add anyone who has a vested interest in Split DWARF in general > and dwp in particular) > > > > tl;dr: > > How should DWARFv4 and DWARFv5 coexist in a DWP file: > > 1) Not at all (invalid/unsupported) > > 2) Single index table where the section indexes are subjective (look at > the version of the referenced CU/TU to decide what a column number means > (eg: 8 is DW_SECT_MACRO in v4, DW_SECT_RNGLISTS in v5) > > 3) Emit multiple indexes (cu_index and tu_index each would contain two > indexes) - a v4 (well, index version 2) and a v5 (index version 5) index. > > What about option 4)? :P Have the numbers be interpreted relative to > the debug_cu_index version number? > The idea would be that a DWARF v4 (dwp tool seems to use version > number 2 for some reason) Yeah - the version 2 comes from the pre-standard development iterations ( https://gcc.gnu.org/wiki/DebugFissionDWP documents version 2/mentions the existence of version 1) > debug_cu_index would keep using the existing > pre-standard scheme, and it would not be able to refer to v5 units. In > a v5 debug_cu_index (*), we would use the official DWARF v5 scheme, > *but* we would, as an extension, support referring to the pre-standard > sections via custom DW_SECT constants (with some high numbers to avoid > conflicting with future standard versions). > Yeah, extending the v5 format might be a good idea. I'm open to that. Pity that there wasn't a standard extension space in the DWP spec to make that smoother. The existence of macinfo and macro in the pre-standard version perhaps could've been a hint that non-standard extensions might be needed (debug_macro being a non-standard extension itself). > (*) The v5 cu_index would be used whenever we have at least one v5 > dwarf unit. Ignoring the section number mismatches, I think this is a > reasonable approach, and it is the one I would make if I was in the > shoes of the DWARF v6 committee and needed to make the debug_cu_index > cover mixed-version units > Speaking of DWARF v6, I think the debug_cu/tu_index sections are in > need of some redesign anyway. For example, it's not clear to me how > these sections would work in presence of DWARF64 -- all section > offsets are hardcoded to 4 bytes, and we don't even have the > initial_length mechanism to select bigger sizes. > Yep - and if we're enumerating things to keep in mind for v6 here: probably collapse the tu_index and cu_index, just index all the things together in one index, probably? They're all indexed by signatures and they're all in the same section now. Good point about DWARF64 there. (I feel like, if possible, all the DWARF contribution headers should be "DWARF32/64 length, then version, then stuff..." - but I guess that might mean needing to rename some sections again... (I think debug_macro missed this too - it has no length, just a version). Without the length first, then contributions can't be skipped over by dumpers & such if they don't understand the version. But maybe that's not a major goal, I guess. You can still read the ones you understand by starting at the debug_info section and going from there to find the contributions for versions you do understand. > > cheers, > pavel >
_______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
