On Wed, Mar 10, 2021 at 10:27 AM Jakub Jelinek via Dwarf-Discuss < dwarf-discuss@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 executable) 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 value. > Do split debug info consumers > need to essentially merge the attributes from the skeleton unit and > corresponding compile unit? > Essentially, yeah. - Dave
_______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
