[Bug debug/105088] New: Small DWARF 5 spec violation in line table when passing an absolute path

[Bug debug/105088] New: Small DWARF 5 spec violation in line table when passing an absolute path

[simon.marchi at polymtl dot ca]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105088

            Bug ID: 105088
           Summary: Small DWARF 5 spec violation in line table when
                    passing an absolute path
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: simon.marchi at polymtl dot ca
  Target Milestone: ---

With:

$ gcc --version
gcc (GCC) 11.2.0
$ as --version
GNU assembler (GNU Binutils) 2.38


I have a source file at /tmp/cwd/test.c and compile it with:

$ gcc /tmp/cwd/test.c -g3 -O0 -gdwarf-5

The DW_AT_name of the CU is "/tmp/cwd/test.c":

    <12>   DW_AT_name        : (line_strp) (offset: 0xd): /tmp/cwd/test.c

The entry at index 0 in the file names table, in the line table header, is
"test.c":

0       (udata) 1       (line_strp)     (offset: 0x16): test.c

In section 6.2.4 (The Line Number Program Header), bullet 20 (file_names),
DWARF5.pdf says:

> The first entry in the sequence is the primary source file whose file name
exactly matches that given in the DW_AT_name attribute in the compilation
unit debugging information entry.

The debug info produced by the toolchain therefore seems to not respect the
spec: the name of the primary source file in the line table header ("test.c")
does not match the DW_AT_name attribute in the compilation unit DIE
("/tmp/cwd/test.c").

[Bug debug/105088] Small DWARF 5 spec violation in line table when passing an absolute path

[simon.marchi at polymtl dot ca]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105088

--- Comment #1 from Simon Marchi <simon.marchi at polymtl dot ca> ---
Looking at the .s, I see that gcc attempts to pass "/tmp/cwd/test.c" as the
name of the file at index 0:

  .file 0 "/home/simark" "/tmp/cwd/test.c"

If gas did put "/tmp/cwd/test.c" as the name in the line table header, it would
be fine.  But in the gas doc [1]:

> When emitting DWARF2 line number information, .file assigns filenames to the .debug_line file name table. The syntax is:
> 
> .file fileno filename
> 
> The fileno operand should be a unique positive integer to use as the index of the entry in the table. The filename operand is a C string literal enclosed in double quotes. The filename can include directory elements. If it does, then the directory will be added to the directory table and the basename will be added to the file table. 

So, gas always only puts the basename as the name in the line table header,
that's why we end up with just "test.c".

[1] https://sourceware.org/binutils/docs/as/File.html#File

[Bug debug/105088] Small DWARF 5 spec violation in line table when passing an absolute path

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105088

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |needs-bisection
     Ever confirmed|0                           |1
      Known to work|                            |12.0
   Last reconfirmed|                            |2022-03-29
             Status|UNCONFIRMED                 |NEW

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
It works for me with trunk:

 <0><c>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <d>   DW_AT_producer    : (indirect string, offset: 0x0): GNU C17 12.0.1
202
20328 (experimental) -mtune=generic -march=x86-64 -g
    <11>   DW_AT_language    : 29       (C11)
    <12>   DW_AT_name        : (indirect line string, offset: 0x10):
/tmp/obj/gc
c/t.c
...
 The File Name Table (offset 0x30, lines 2, columns 2):
  Entry Dir     Name
  0     0       (indirect line string, offset: 0x3e): /tmp/obj/gcc/t.c
  1     1       (indirect line string, offset: 0x4f): t.c

confirmed with GCC 11, something fixed it.

[Bug debug/105088] Small DWARF 5 spec violation in line table when passing an absolute path

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105088

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
Hmm, I still see it with current trunk:

$ rm test.o ; gcc /tmp/test.c -g3 -O0 -gdwarf-5 -c && readelf --debug-dump
test.o
...
    <12>   DW_AT_name        : (indirect line string, offset: 0x0): /tmp/test.c
...
 The File Name Table (offset 0x34, lines 3, columns 2):
  Entry Dir     Name
  0     1       (indirect line string, offset: 0x64): test.c
  1     1       (indirect line string, offset: 0x6b): test.c

@Richi: How did you run trunk GCC?

[Bug debug/105088] Small DWARF 5 spec violation in line table when passing an absolute path

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105088

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Can't reproduce with current 11 branch either.
Perhaps r12-1777-ga21dc9d1529b8a8071e36b22b6e8492fc2ce7d5a which has been
backported to 11 in r11-8650-gf19b20de1b24d6b53479c6815316a5201b22775d as well?

[Bug debug/105088] Small DWARF 5 spec violation in line table when passing an absolute path

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105088

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
In my case I have binutils 2.35.
Anyway, if newer binutils breaks this, it is binutils fault.
DW_AT_name of the CU in this case has to include the full path, because the
only option it has to supply a path when DW_AT_name is relative is through
DW_AT_comp_dir.  But DW_AT_comp_dir should be the current working directory
which can be and often is completely different from the /tmp/cwd path and some
paths (e.g. of includes) can be relative to the current path.

[Bug debug/105088] Small DWARF 5 spec violation in line table when passing an absolute path

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105088

--- Comment #6 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
This comes from binutils:
  https://sourceware.org/pipermail/binutils/2021-November/118442.html
and I don't think that there is any violation, the file_name is simply
represented by a pair (DW_LNCT_path, DW_LNCT_directory_index).

[Bug debug/105088] Small DWARF 5 spec violation in line table when passing an absolute path

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105088

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That looks incorrect to me, the intent was that it is actually the same string,
that is also why there is DW_FORM_line_strp so that it can actually use the
same string rather than its copy.

[Bug debug/105088] Small DWARF 5 spec violation in line table when passing an absolute path

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105088

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
See the
"Note that if a .debug_line_str section is present, both the compilation unit
debugging information entry and the line number header can share a single copy
of
the current directory name string."
and
"Note that if a .debug_line_str section is present, both the compilation unit
debugging information entry and the line number header can share a single copy
of
the current file name string."
comments.  The reason for the duplication (DW_AT_comp_dir of CU vs. dir 0 entry
in .debug_line and DW_AT_name of CU vs. file 0 entry in .debug_line) is so that
.debug_info can be stripped and .debug_line* kept.

[Bug debug/105088] Small DWARF 5 spec violation in line table when passing an absolute path

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105088

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu.org

--- Comment #9 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> The reason for the duplication (DW_AT_comp_dir of CU vs. dir 0
> entry in .debug_line and DW_AT_name of CU vs. file 0 entry in .debug_line)
> is so that .debug_info can be stripped and .debug_line* kept.

You can still do that, i.e. .debug_line* contains the same information, it's
just encoded differently and more compact.

[Bug debug/105088] Small DWARF 5 spec violation in line table when passing an absolute path

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105088

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org,
                   |                            |mark at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
It is not more compact, because the "/tmp/cwd/test.c" string is already present
in .debug_line_str anyway (for DW_AT_name which uses DW_FORM_line_strp).
CCing some other DWARF committee members for their opinions.

[Bug debug/105088] Small DWARF 5 spec violation in line table when passing an absolute path

[mark at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105088

--- Comment #11 from Mark Wielaard <mark at gcc dot gnu.org> ---
I believe the intention of the DWARF5 spec as that dir entry zero would be
equal to the comp_dir attribute of the CU and file entry zero would be equal to
the name attribute of the CU.

Also, although the spec does not explicitly seem to say so, consumers take an
absolute source path to mean that the file isn't relative to the compilation
dir.

So if the current working directory is my home dir and I compile a source file
/tmp/test.c then I would expect the Compile Unit DIE to have the following two
attributes:

           name                 (line_strp) "/tmp/test.c"
           comp_dir             (line_strp) "/home/mark"

And the dir/line table to match with:

Directory table:
      [path(line_strp)]
 0     /home/mark (23)

File name table:
      [path(line_strp), directory_index(udata)]
 0     /tmp/test.c (52),  0

gcc tries to make that happen using the following .file 0 entry:

        .file 0 "/home/mark" "/tmp/test.c"

So if that is no longer the case, then I think binutils gas is getting this
wrong now.