[Dwarf-Discuss] DW_AT_decl_file etc understood now. Question answered.

[Robinson, Paul]

> -----Original Message-----
> From: Dwarf-Discuss <dwarf-discuss-bounces at lists.dwarfstd.org> On Behalf
> Of Philip Craig via Dwarf-Discuss
> Sent: Monday, February 17, 2020 10:02 PM
> To: David Anderson <davea42 at linuxmail.org>
> Cc: dwarf-discuss at lists.dwarfstd.org
> Subject: Re: [Dwarf-Discuss] DW_AT_decl_file etc understood now. Question
> answered.
> 
> On Tue, 18 Feb 2020 at 10:40, David Anderson via Dwarf-Discuss
> <dwarf-discuss at lists.dwarfstd.org> wrote:
> >
> > A bit of thought, and it becomes clear. Since 0 is a reserved
> > (and always has been)
> > value for DW_AT_decl_file the numbers used by the compiler
> > must start at 1.
> >
> > So to index into the array of names from the line table header
> > make sure your value is greater than zero and
> > subtract 1 from the DW_AT_decL_file.
> >
> > With DWARF5 the file numbered 1 has to be the file of the compilation
> unit
> > (same as DW_AT_name of the compilation unit).
> 
> That seems wrong to me. That would mean that the index used for
> DW_AT_decl_file is different from the index used for DW_LNS_set_file,
> which uses values beginning with 0. From Section 6.2.4:
> 
> "The line number program references file names in this sequence beginning
> with 0, and uses those numbers instead of file names in the line number
> program that follows."
> 
> It goes on to say:
> 
> "Prior to DWARF Version 5, the current compilation file name was not
> represented in
> the file_names field. In DWARF Version 5, the current compilation file
> name is
> explicitly present and has index 0. This is needed to support the
> common practice of
> stripping all but the line number sections ( .debug_line and
> .debug_line_str )
> from an executable."
> 
> but I think that statement is wrong. Prior to DWARF Version 5, the
> currently compilation file name was an entry in the file_names field,
> just like any other entry.

That was also my interpretation when I implemented the Clang handling
for DWARF v5.

I've always understood that line #0 meant "no specific source location
specified" rather than "no specific line within the specified file."
That is, we did *not* have to set both file and line to 0 in order to
say "no specific source location."  (Setting both would noticeably
increase the size of the line table, as setting the file to 0 and back
requires two extended opcodes, i.e. minimum of 6 bytes per instruction
(or adjacent set) with no explicit source location.)

And with file #0 being explicitly listed in the .debug_line header,
my prior intuitive understanding continues to make sense.

I think we should fix the description of DW_AT_decl_file so that
file #0 means either file #0 from the .debug_line header, or the file
named by DW_AT_name in the CU header.
--paulr

> 
> Note that this is different from the handling for the compilation
> directory, where for DWARF4 an index of 0 is valid and refers to the
> implicit entry that is the DW_AT_comp_dir attribute.
> 
> Additionally, clang-10 emits DW_AT_decl_file values of 0 that seem to
> be meant to refer to the compilation file, even though the standard
> says 0 means no source file has been specified.
> 
> For my DWARF5 producer, I avoid the issue by emitting an entry at
> index 0 but never referencing it.
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org