[Dwarf-Discuss] line table dir/file

[Philip Craig]

On Tue, 25 Feb 2020 at 05:34, Robinson, Paul via Dwarf-Discuss
<dwarf-discuss at lists.dwarfstd.org> wrote:
> When the committee was reworking the file/dir tables for DWARF v5,
> one thing that came up was that the root file/directory were *not*
> in the .debug_line section, and therefore the line table could not
> be interpreted fully without a .debug_info section, because that
> was where the root file and compilation directory were kept--not
> in the line table itself.  Am I imagining this discussion?  We
> added text to the document specifically describing file/dir 0 and
> that they were to be explicitly kept (duplicated from .debug_info)
> so that the .debug_line section could be fully dumped even in the
> absence of a corresponding .debug_info section.  This was the
> "strip all but the line table" scenario.

That matches the reasoning given in the informative paragraphs in
Section 6.2.4. As I've mentioned before, it seems partially flawed,
since I think it was only the compilation directory that was required
from the .debug_info section. The root file change seems unnecessary,
and I am unsure if it is a good change (it's an unnecessary change
which increases chances of implementation bugs, particularly since it
is not isolated to .debug_line, but it makes the file and directory
indexing consistent).

> Offhand it looks like there are three possibilities:
> a) Clang got it right and everyone else got it wrong.
> b) The spec is ambiguous and we're observing the consequences.
> c) Clang got it wrong and everyone else got it right.

I don't think it's "Clang" vs "everyone else" because the only v5
.debug_line producer that David looked at was Clang, and no consumers
were looked at.

gdb appears to accept an index of 0 for v5 .debug_line, including for
DW_AT_decl_file. I didn't test, but only looked at its source code.

libbacktrace handles v5 .debug_line, but uses 1-based indexing for
both DW_LNS_set_file and DW_AT_call_file. This may be an
implementation bug such as I mentioned above.
https://github.com/ianlancetaylor/libbacktrace/blob/ca0de0517f3be44fedf5a2c01cfaf6437d4cae68/dwarf.c#L3171

> But in all three cases, we need to settle on (i) what the spec
> actually says, (ii) does it say what the committee intended,
> (iii) if not, what to do about it.

For (i), the spec says two things that seem conflicting to me:

Section 2.14, Page 50:
The value of the DW_AT_decl_file attribute corresponds to a file
number from the line number information table for the compilation unit
containing the debugging information entry and represents the source
file in which the declaration appeared (see Section 6.2 on page 148).
The value 0 indicates that no source file has been specified

Section 6.2.4, Page 158:
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.

I think there is no doubt that this intends the line number program to
use 0-based indexing. I think it is reasonable to assume that
DW_AT_decl_file uses the same numbering as the line number program.
But doing so means DW_AT_decl_file cannot reference the first file
name since a value of 0 indicates no source file has been specified.

One possibility is that Section 2.14 was missed when updating the
standard for the new file name entry at index 0, and that a
DW_AT_decl_line of 0 is sufficient to indicate no source file.