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

Reply via email to