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

David Anderson davea42@linuxmail.org
Tue Sep 1 03:22:42 GMT 2020

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_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?


More information about the Dwarf-discuss mailing list