Hi Omar, On Thu, Feb 22, 2024 at 05:03:44PM -0800, Omar Sandoval wrote: > On Thu, Feb 22, 2024 at 04:53:19PM -0800, Omar Sandoval wrote: > > On Fri, Feb 16, 2024 at 04:00:47PM +0100, Mark Wielaard wrote: > > > 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. > > Ah, I guess you can call dwarf_getsrclines/dwarf_next_lines on the dwp > file itself, where DW_SECT_LINE may be applicable. I need to think about > that some more...
So reading the DWARF5 spec, it says a split DWARF CU/TU DIE may have a DW_AT_stmt_list, which are interpreted as relative to the base offset for .debug_line.dwo. And these tables contain only the directory and filename lists needed to interpret DW_AT_decl_file attributes in the debugging information entries. Actual line number tables remain in the .debug_line section, and remain in the relocatable object (.o) files. So I think the intention is that the main .debug_line (skeleton) section does contain the actual line number table, but only those file/dir table entries that are referenced from that. Not any that are only referenced from the DW_AT_decl_file attributes (which should only appear in the split DWARF DIEs). Maybe in practice these overlap completely, so there is no savings and they are in practice identical. But I don't see anything in the spec that implies you should interpret a lineptr in the .debug_info.dwo as relative to the .debug_line section in the skeleton. Cheers, Mark