On Mon, Mar 30, 2020, 5:37 PM David Blaikie <dblai...@gmail.com> wrote:
> > > On Sun, Mar 29, 2020 at 3:44 PM Cary Coutant <ccout...@gmail.com> wrote: > >> >> > Yep - unless someone has significant objections my plan is currently: >> >> > >> >> > Emit a v5 index with extension/non-standard extra column indexes >> (specifically: DW_SECT_LOC and 9 and DW_SECT_MACINFO at 10). I hope those >> can at least be reserved (like DW_SECT value 2 (originally DW_SECT_TYPES) >> was in DWARFv5) in DWARFv6. & maybe open up an extension space in the >> future. >> >> >> >> That sounds good to me. When I saw that number 2 (debug_types in the >> >> fission extension) was reserved, I originally assumed this was what >> >> had already happened. >> >> The pre-v5 dwp format was just a prototype, accessed via >> --experimental GCC flags, and I don't think we ever intended to >> support mixing pre-v5 dwo files with standard v5 dwo files. I'd >> recommend your original option #1 (invalid/unsupported). Thus, you >> shouldn't need DW_SECT_LOC or DW_SECT_MACINFO. >> > > That'd be really difficult (I think I'd go so far as to say - it wouldn't > be done that way) for an environment like Google (or other large projects) > that want to change the default. It's important not to get into a situation > where the flag flip from v4 to v5 is overridable, so that we can readily > opt-out of v5 on a per translation unit basis if there happen to be a > handful of translation units that trip over uncommon bugs without having to > rollback the whole codebase each time we hit something like that. > > So I'd say at the very least, I think we'll implement a v4+v5 index in our > internal port of binutils/gold dwp and gdb - and I'd really hope to be able > to upstream those for anyone else who might be in a similar situation. > > I guess it's possible we could opt-out of split DWARF and opt out of v5 > for such translation units (though there's currently no flag to undo > -gsplit-dwarf on the command line -ah, there is in GCC (-gno-split-dwarf) > but not in Clang, so we could add that). Does make things a bit awkward, > but not impossible, and seems like in the future we're going to have to > keep backwards compatibility too, so wouldn't be so bad to keep it for v4 > too, would it? > Also anyone having to deal with precompiled objects... > >> >> The .debug_types sections were moved back into .debug_info sections at >> the very last minute, so we just removed DW_SECT_TYPES without >> renumbering the later values. As best I recall, that was just a nod >> towards some compatibility with the prototype format, but it wasn't >> intended to provide for complete compatibility. >> >> I don't believe we ever supported .debug_macinfo in the prototype, so >> I wasn't concerned with the renumbering around DW_SECT_MACRO and >> DW_SECT_MACINFO. >> >> I agree that we should have reserved an extension range for DW_SECT >> values. It's probably safe to pick some arbitrarily large values if >> you need to extend this. >> >> For DWARF-64 support, I truly hoped that we wouldn't ever need it, but >> if it was ever necessary, the mechanism I had in mind was to simply >> replace .debug_cu_index sections with .debug_cu_index_64 sections (and >> likewise for .debug_tu_index). Maybe DWARF v6 will address this. Keep >> in mind that the .dwp can be an ELFCLASS64 object file, and its total >> size can grow larger than 4GB, even if .debug_cu_index can't support >> any section offsets larger than 4GB. >> >> -cary >> >
_______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
