[Dwarf-Discuss] More on DW_AT_str_offset_base debug_str_offsets.dwo confusion

[David Blaikie]

On Mon, Aug 31, 2020 at 8:22 PM David Anderson <davea42 at linuxmail.org>
wrote:

> On 8/31/20 1:03 PM, David Blaikie wrote:
> > I'd rather go with LLVM's existing interpretation - that strx
> > encodings used in .dwo do not attempt to use str_offsets in the skeleton.
> > But I wouldn't mind adding a str_offsets_base to the split full unit
> > to make it clear - this would be consistent with rnglists, I think? (I
> > think, in theory a rnglistx in a .dwo with a split full unit without a
> > rnglists_base would use the rnglists_base (and .debug_rnglists
> > non-dwo) in the executable, but if the split full unit has a
> > rnglists_base, then the rnglistx in the split full unit use that base
> > to find rnglists in debug_rnglists.dwo - arguably I'd say we might as
> > well say the same thing about loclists, too, for consistency, though I
> > don't have any use for skeleton location lists right now)
>
> It seems to me that rnglists base and loclists_base in Split Full always
> reference the data in .debug_rnglists/.debug_loclists
>
> 3.1.3  Split Full Compilation Unit Entries
> The following attributes are not part of a split full compilation unit
> entry but instead are
> inherited (if present) from the corresponding skeleton compilation unit:
> DW_AT_low_pc,
> DW_AT_high_pc, DW_AT_ranges, DW_AT_stmt_list, DW_AT_comp_dir,
> DW_AT_str_offsets_base, DW_AT_addr_base and DW_AT_rnglists_base.
>

Hmm... yeah. I guess LLVM implements rnglistx /rnglist_base the same as
strx/str_offsets_base. Where it assumes that any *x encoding refers to
entities in the .dwo, even in the absence of a
rnglists_base/str_offsets_base in the split full unit. I had thought we'd
implemented it to emit a rnglists_base in the split full unit, which
would've been in contrast to the str_offsets_base - so my mistake/apologies
for the previous description.


> I forgot that rnglists and loclists can use address x things so they
> could exist in a .dwo an
> so those too could potentially need/want different tables  the .dwo vs
> the non-dwo.
> So now I'm thinking you  are correct.
>
> This needs an ISSUE on on dwarfstd.org. You could file one.
>
> Or I could ask Michael Eager to modify what I filed today (probably not
> visible on Dwarstd.Org yet) to specify your approach as the
> better one.
> Your preference?
>

No strong feelings - how about we just keep your one and generalize it over
strx, rnglistx, and loclistx: The spec needs to say
clearly/non-contradictorily that loclist_base/rnglist_base/str_offsets_base
are not needed in the split full unit, and not inherited from the skeleton
unit (this limits producers a bit - it doesn't give them the choice to
share the entities between the skeleton and split-full*) - or, that they
are inherited and thus do need to be specified/must be allowed in the split
full unit if you want to use str_offsets_base.dwo, rnglists.dwo, or
loclists.dwo.

* this doesn't seem like super important flexibility to have - importantly
it still wouldn't let you mix-and-match (it wouldn't let you reference both
str_offsets and str_offsets.dwo in the same split full unit (well, I guess
any strings appearing on the split full unit prior to any str_offsets_base
attribute? that would be subtle and I'd rather avoid that being an option)
- it'd be all one or all the other & you really wouldn't want to put all
your strings in the .o/executable as you'd lose most of the benefit of
split DWARF - keeping all your ranges in the .o/executable really isn't
ideal either, but I could imagine someone might choose that to simplify
their implementation while gaining many/most of the benefits of Split DWARF
- I really wouldn't encourage it & wouldn't want the spec to make a choice
on the basis of that use case)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20200831/589c7edf/attachment.html>