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

[Ron Brender]

Responding to Cary's question several exchanges back

>Do you remember why kept DW_AT_ranges in the skeleton CU even after we
>moved the range lists to the dwo? Was it the intent all along that the
>DW_AT_ranges attribute in the skeleton CU would reference the
>.debug_rnglists section, while DW_AT_ranges attributes in .dwo
>sections would reference the .debug_rnglists.dwo section?

In a word, No, I don't recall. Having not thought about this for four years
now I
can't recover that level of discussion. I do recall that trying to pin down
which
attributes could be used on the skeleton and which in the .dwo was
confusing at
times. Clarification and/or tweaking as discussed here seems appropriate
AFAICT.

Ron


Sorry, Ron

On Thu, Mar 11, 2021 at 4:50 AM David Blaikie via Dwarf-Discuss <
dwarf-discuss at lists.dwarfstd.org> wrote:

>
>
> 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
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20210311/b126c66e/attachment.html>