On Thu, Mar 11, 2021 at 1:39 AM Jakub Jelinek <ja...@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@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
