[PATCH] D34765: [DWARF] [NFC] Move a couple of member functions to DWARFUnit (baseclass) from DWARFCompileUnit (derived class)

[Wolfgang Pieb via Phabricator via llvm-commits]

wolfgangp added a comment.

In https://reviews.llvm.org/D34765#794773, @dblaikie wrote:

> In https://reviews.llvm.org/D34765#794516, @wolfgangp wrote:
>
> > In https://reviews.llvm.org/D34765#794069, @dblaikie wrote:
> >
> > > This is for DW_AT_str_offsets_base in a type unit?
> >
> >
> > Yes.
> >
> > > Is the delta version needed? (is that modifying the existing use in split DWARF to now require a tag for str_offsets_base when none was needed before) Or only the addSectionLabel?
> >
> > The delta version avoids generating relocations, which we can't have for split DWARF, so for version >=5 the plan is to generate the str_offsets_base tag using addSectionLabel() for when we can use relocations and addSectionDelta() for when we can't (such as split DWARF, or Mach-O).
>
>
> Right, sorry I wasn't very clear - what I was asking is: In DWARF5 do .dwo CUs have a str_offsets_base? They didn't in the pre-standard Fission that's implemented in LLVM at the moment - because the value was effectively zero always.


No you're right, my bad. Units in the .dwo sections (both type and CU) don't have a str_offsets_base, which implies that the .debug_str_offsets.dwo section has to consist of a monolithic table of string offsets (without the 8 or 16-byte header that's specified in section 7.26 of the DWARF 5 standard).  Section 7.26 seems to say the opposite, though. It seems I'll have to clarify this with the DWARF5 folks.

In any case, I think the Delta is still needed for str_offsets_base (and addr_base) in file formats that don't seem to support cross section relocations (like Mach-O).


https://reviews.llvm.org/D34765