[Dwarf-Discuss] DWP mixed (DWARFv4/pre-standard + DWARFv5) content

[Eric Christopher]

On Mon, Mar 30, 2020, 5:37 PM David Blaikie <dblaikie at gmail.com> wrote:

>
>
> On Sun, Mar 29, 2020 at 3:44 PM Cary Coutant <ccoutant at 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20200330/60a5bf3a/attachment-0001.html>