[Dwarf-Discuss] More on DW_AT_str_offset_base debug_str_offsets.dwo confusion
I has occurred to me that simply restricting skeleton CUs to use DW_FORM_string or DW_FORM_strp would restore the unique meaning of DW_AT_str_offsets_base to apply to the dwp (letting non-skeleton CUs use DW_FORM_strx1 etc ). With seemingly little impact on overall size. DavidA. ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] More on DW_AT_str_offset_base debug_str_offsets.dwo confusion
On Mon, Aug 31, 2020 at 10:33 AM David Anderson via Dwarf-Discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > I has occurred to me that simply restricting skeleton CUs > to use DW_FORM_string or DW_FORM_strp > would restore the unique meaning of DW_AT_str_offsets_base > to apply to the dwp (letting non-skeleton CUs use > DW_FORM_strx1 etc ). With seemingly little impact on > overall size. > Seems a pity for orthogonality (and for a non-standard/extension use that LLVM has, where skeleton units carry some DIEs (essentially "gmlt"-like data, enough to symbolize with inline stack frames) in the skeleton CU - not being able to used indexed strings would be an object size penalty due to potentially needing to use more relocations) I think the DWARFv5 spec is a bit conflicted, but does have some wording that supports LLVM's existing usage: ".debug_info.dwo to .debug_str_offsets.dwo: Attribute values of class string may have one of the forms DW_FORM_strx, 3 DW_FORM_strx1, DW_FORM_strx2, DW_FORM_strx3 or 4 DW_FORM_strx4, whose value is an index into the .debug_str_offsets.dwo section for the corresponding string" "The string table section in .debug_str.dwo contains all the strings referenced from DWARF attributes using any of the forms DW_FORM_strx, DW_FORM_strx1, DW_FORM_strx2, DW_FORM_strx3 or DW_FORM_strx4. Any attribute in a compilation unit or a type unit using this form refers to an entry in that unit’s contribution to the .debug_str_offsets.dwo section, which in turn provides the offset of a string in the .debug_str.dwo section." (& some that contradicts it): "The DW_AT_addr_base and DW_AT_str_offsets_base attributes provide context that may be necessary to interpret the contents of the corresponding split DWARF object file." "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." 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) ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] More on DW_AT_str_offset_base debug_str_offsets.dwo confusion
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. 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? DavidA. ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] More on DW_AT_str_offset_base debug_str_offsets.dwo confusion
On Mon, Aug 31, 2020 at 8:22 PM David Anderson 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
