On Fri, Feb 16, 2024 at 04:00:47PM +0100, Mark Wielaard wrote: > Hi Omar, > > On Wed, 2023-12-06 at 01:22 -0800, Omar Sandoval wrote: > > The final piece of DWARF package file support is that offsets have to be > > interpreted relative to the section offset from the package index. > > .debug_abbrev.dwo is already covered, so sprinkle around calls to > > dwarf_cu_dwp_section_info for the remaining sections: .debug_line.dwo, > > .debug_loclists.dwo/.debug_loc.dwo, .debug_str_offsets.dwo, > > .debug_macro.dwo/.debug_macinfo.dwo, and .debug_rnglists.dwo. With all > > of that in place, we can finally test various libdw functions on dwp > > files. > > So the offsets for DW_SECT_INFO, DW_SECT_TYPES and DW_SECT_ABBREV were > already taken into account when setting up a cu from a dwp. > > With this patch __libdw_cu_str_off_base/str_offsets_base_off handles > DW_SECT_STR_OFFSETS which is used in dwarf_formstring and > dwarf_getmacros. > > __libdw_cu_ranges_base handles DW_SECT_RNGLISTS, which is used by > dwarf_ranges. And __libdw_formptr has a special case for > DW_FORM_sec_offset for IDX_debug_ranges && version < 5 && unit_type == > DW_UT_split_compile to also uses __libdw_cu_ranges_base. > > __libdw_cu_locs_base handles DW_SECT_LOCLISTS which is used in > dwarf_getlocation through initial_offset. I do wonder why the special > case in __libdw_formptr isn't needed here too. > > dwarf_getmacros handles DW_SECT_MACRO through get_offset_from. And when > the macros need to refer to the line table, it also handles > DW_SECT_LINE. > > Don't we also need to handle DW_SECT_LINE in dwarf_getsrclines and > dwarf_next_lines when looking for DW_AT_stmt_list?
.debug_line is the odd one out in split DWARF: the skeleton file contains the full .debug_line, and the DWO or DWP files have a skeleton .debug_line.dwo that only contains the directory and file name tables (for DW_AT_file and macro info to reference). dwarf_getsrclines and co. read from the skeleton file, not the DWP file, meaning they shouldn't use DW_SECT_LINE. > > * libdw/dwarf_getmacros.c (get_macinfo_table): Call > > dwarf_cu_dwp_section_info and add offset to line_offset. > > (get_offset_from): Call dwarf_cu_dwp_section_info and add offset > > to *retp. > > * libdw/libdwP.h (str_offsets_base_off): Call > > dwarf_cu_dwp_section_info and add offset. > > (__libdw_cu_ranges_base): Ditto. > > (__libdw_cu_locs_base): Ditto. > > * libdw/dwarf_getlocation.c (initial_offset): Call > > dwarf_cu_dwp_section_info and add offset to start_offset. > > * tests/run-varlocs.sh: Check testfile-dwp-5 and testfile-dwp-4. > > * tests/run-all-dwarf-ranges.sh: Check testfile-dwp-5 and > > testfile-dwp-4. > > * tests/run-dwarf-getmacros.sh: Check testfile-dwp-5 and > > testfile-dwp-4-strict. > > * tests/run-get-units-split.sh: Check testfile-dwp-5, > > testfile-dwp-4, and testfile-dwp-4-strict. > > The code and tests look good. run-varlocs.sh seems good, which seems to > confirm DW_SECT_LOCLISTS is handled correctly (but why doesn't it need > a hack similar to ranges in __libdw_formptr?). I think it's because ranges have the uniquely weird behavior in DWARF 4 GNU Debug Fission that DW_AT_GNU_ranges_base is in the skeleton file but used to interpret the split file. This was cleaned up for DWARF 5 (as I documented in commit c9c9ffae725009b192b40e2d89035f353ae7055f), and there was no base attribute for location lists in DWARF 4, so it's not applicable. > We might want to add a test for run-next-lines.sh and run-next- > files.sh? Good idea, I'll send an updated version with those tests. Thanks! Omar
