[Dwarf-Discuss] Split Dwarf vs. CU DW_AT_ranges / DW_AT_low_pc placement

David Blaikie dblaikie at gmail.com
Wed Mar 10 11:18:32 PST 2021

On Wed, Mar 10, 2021 at 10:27 AM Jakub Jelinek via Dwarf-Discuss <
dwarf-discuss at lists.dwarfstd.org> wrote:

> Hi!
> We got a report today that GCC even for -gdwarf-5 -gsplit-dwarf uses
> .debug_rnglists section + DW_AT_ranges + DW_AT_low_pc + DW_AT_rnglists_base
> attributes in the DW_TAG_skeleton_unit (and then some DW_AT_ranges in
> .debug_info.dwo that use DW_FORM_rnglistx, but no .debug_rnglists.dwo
> section).

Oh, good to know!

> That is the same spot where
> the DWARF 4 split DWARF extension was using, but the .debug_ranges
> section wasn't really placeable into dwo files.
> So, my first question is whether that is really invalid DWARF 5 or not.

I think the spec is ambiguous here:

3.1.3 "The following attributes are not part of a split full compilation
unit entry but instead are 18 inherited (if present) from the corresponding
skeleton compilation unit: DW_AT_low_pc, 19 DW_AT_high_pc, DW_AT_ranges,
DW_AT_stmt_list, DW_AT_comp_dir, 20 DW_AT_str_offsets_base, DW_AT_addr_base
and DW_AT_rnglists_base."

So, on the one hand, if rnglists_base is inherited that implies that
rnglists_base on a skeleton CU means rnglists.dwo is not used. (so the only
way to use rnglists.dwo is to not have rnglists_base on the skeleton CU and
you don't have it on the split full CU and /that's/ how rnglistx in split
full unit refer to rnglists.dwo instead of debug_rnglists in the linked

Honestly it wouldn't be too bad if that's the determination (except for
legacy support for LLVM's current emission, even if it's determined to be
buggy by this decision) - using rnglists_base on the skeleton CU isn't
super valuable - you only have one rnglist on the CU usually (short of
having any novelty extension attributes that might want to use rnglistx - I
don't know of any), so there's no relocation savings/sharing by using
rnglists_base+rnglistx for DW_AT_ranges.

Conversely, I would encourage GCC to use rnglists.dwo one way or another
(either using LLVM's current protocol, or sidestepping the issue by using
sec_offset+DW_AT_ranges on the skeleton unit to avoid the rnglists_base on
the skeleton unit and subsequent ambiguity) as it significantly reduces
object/executable size for optimized builds using Split DWARF.

> LLVM seems to emit instead:
> .debug_rnglists section + DW_AT_ranges + DW_AT_low_pc + DW_AT_rnglists_base
> attributes in the DW_TAG_skeleton_unit (but .debug_rnglists only contains
> the ranges for the whole CU) and then
> .debug_rnglistsx.dwo section and DW_AT_ranges in .debug_info.dwo (not on
> the
> DW_TAG_compile_unit though) that refer to that.

Yep, I can confirm that's how LLVM does it/how it was intentionally
implemented, and that the absence of rnglists_base in the split full unit
does create some ambiguity about what a rnglistx encoding in a split full
unit refers to.

> Would it be ok to emit only DW_AT_low_pc in DW_TAG_skeleton_unit and
> .debug_rnglists.dwo section and DW_AT_ranges (but not DW_AT_rnglists_base)
> in DW_TAG_compile_unit?  I mean, is there any benefit in having the CU
> ranges on the skeleton over .debug_info.dwo?

Yeah, that would probably be problematic (I think the spec specifically
calls out that low/high/ranges for the CU should be on the skeleton) -
there's a lot of value in being able to identify the unit that covers a
certain address without having to load the corresponding dwo file.
Especially for systems with high-latency (remote/distributed filesystem,
etc) access to dwo files, the ability to not load dwo files is super high

>   Do split debug info consumers
> need to essentially merge the attributes from the skeleton unit and
> corresponding compile unit?

Essentially, yeah.

- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20210310/16d466e0/attachment.html>

More information about the Dwarf-Discuss mailing list