On Mon, Aug 31, 2020 at 8:22 PM David Anderson <dave...@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)
_______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
