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

[David Blaikie]

On Thu, Mar 11, 2021 at 1:39 AM Jakub Jelinek <jakub at redhat.com> wrote:

> On Thu, Mar 11, 2021 at 01:05:06AM -0800, David Blaikie wrote:
> > What's your take on:
> >
> > 1) Fixing GDB to handle GCC's current output.
>
> I don't know what GDB will do, it is up to the GDB people.
>
> > 2) Fixing GCC to produce something maybe more standards conforming (to my
> > mind, ideally: ranges on the skeleton CU (using either
> > rnglists_base+rnglistx (like LLVM), or sec_offset (actually more
> > compact/better than LLVM anyway, and avoids the ambiguous situation), and
> > rnglistx in child DIEs the split full unit using using
> .debug_rnglists.dwo)
>
> Given the
> 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, 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."
> sentence, at least for DWARF5 putting DW_AT_ranges into the full unit
> rather
> than skeleton unit for split DWARF seems like non-conforming, so I'll
> probably adjust my patch, but see below.
> Now, for DW_AT_addr_base and DW_AT_rnglists_base the spec talks about
> it affecting just .debug_addr or .debug_rnglists section, doesn't mention
> the .debug_rnglists.dwo section, while for DW_AT_str_offsets_base it talks
> about .debug_str_offsets or .debug_str_offsets.dwo.
> So, maybe one reason why DW_AT_rnglists_base might be ok on the skeleton
> unit.  On the other side, e.g. in Table F.1 I see there for Skeleton and
> Split:
> DW_AT_low_pc - Skeleton only
> DW_AT_ranges - Split Full only (so, in contradition of 3.1.3)
> DW_AT_rnglists_base - not present
> So, DWARF5 is inconsistent.  But appendix F is informative and so I think
> the normative 3.1.3 wins.
>

Yup, I hope to get those inconsistencies addressed through an issue I've
filed earlier today. Glad for the discussion/confirmation/etc.


> So, I think I'll go with DW_AT_ranges and DW_AT_low_pc in
> DW_TAG_skeleton_unit, but the former using DW_FORM_sec_offset rather than
> DW_FORM_rnglistx and no DW_AT_rnglists_base (I really don't see a benefit
> of that, there is one relocation either way, either on the DW_AT_ranges
> with DW_FORM_sec_offset or on DW_AT_rnglists_base with DW_FORM_sec_offset,
> but for the latter one needs one byte for the DW_FORM_rnglistx too and
> two extra bytes in .debug_abbrev.  DW_FORM_rnglistx can be beneficial if
> there
> is more than one range, which is not the case for the skeleton.
>

Yep, that's my take on it too - while I can argue that the LLVM output
is/should be valid, it's not the most efficient, and the most efficient
(using sec_offset for ranges on the skeleton CU) dodges this particular
question of validity - sounds good to me.


> But .debug_rnglists I'll probably use the *x suffixed DW_RLE_* opcodes when
> DW_RLE_offset_pair can't be used even in the skeleton .debug_rnglists.
>

Yeah, I can certainly +1 to that. Sharing the debug_addr entries is great
for object file size.

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