[Bug debug/101431] New: gcc-generated DWARF5 .debug_line directory entries violate the DWARF5 spec

[Bug debug/101431] New: gcc-generated DWARF5 .debug_line directory entries violate the DWARF5 spec

[roc at ocallahan dot org]

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

            Bug ID: 101431
           Summary: gcc-generated DWARF5 .debug_line directory entries
                    violate the DWARF5 spec
           Product: gcc
           Version: 11.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: roc at ocallahan dot org
  Target Milestone: ---

For the "Line Number Program Header" "directories" field, the DWARF5 spec says

"The first entry is the current directory of the compilation. Each additional
path entry is either a full path name or is relative to the current directory
of
the compilation."

In a simple testcase (see below) I get the following tables emitted (gcc
11.1.1):

The Directory Table:
  0 out
  1 out
  2 /usr/include

The File Name Table
  Entry Dir     Time    Size    Name
  0     0       0       0       file.c
  1     1       0       0       file.c
  2     1       0       0       message.h
  3     2       0       0       stdio.h

The compilation unit info from .debug_info is

UNIT<header overall offset = 0x0000006a>:
  dwo_id           = 0x6ef97fe679ccccda
< 0><0x00000014>  DW_TAG_skeleton_unit
                    DW_AT_low_pc                0x00201728
                    DW_AT_high_pc               <offset-from-lowpc>21
                    DW_AT_stmt_list             <.debug_line+0x000000bd>
                    DW_AT_dwo_name              out/main.dwo
                    DW_AT_comp_dir              /tmp/pernosco-submit-test
                    DW_AT_GNU_pubnames          yes
                    DW_AT_addr_base             <.debug_addr+0x00000030>

The correct path for 'file.c' is /tmp/pernosco-submit-test/out/file.c.

Clearly, treating directory entry 1 as relative to directory entry 0 would give
the wrong file path (something containing 'out/out'). It looks like gcc intends
all directory entries to be treated as relative to the DW_AT_comp_dir from the
.debug_info unit?

Note that if the latter is true, then that violates the intent of the new
behavior in DWARF5:

> In DWARF Version 5, the current directory is explicitly present in the
directories field. 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.

To reproduce this bug:

git clone --recurse-submodules https://github.com/Pernosco/pernosco-submit-test
cd pernosco-submit-test
./build.sh
dwarfdump -l out/main.debug

[Bug debug/101431] gcc-generated DWARF5 .debug_line directory entries violate the DWARF5 spec

[roc at ocallahan dot org]

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

--- Comment #1 from roc at ocallahan dot org <roc at ocallahan dot org> ---
Clang follows the spec (clang 12, -fdebug-default-version=5):

The Directory Table:
  0 /tmp/pernosco-submit-test
  1 out

The File Name Table
  Entry Dir     Time    Size    MD5                                     Name
  0     0       0       0       F596F6F042BF2AD9E2B1C6B62633739A       
out/file.c
  1     1       0       0       5E2CEC2A6335E978DEB5A35D865C41E2       
message.h

So I'm not sure what to do anymore when consuming DWARF5 line number
information.

I guess we could try "treat all relative directory entries as relative to the
DW_AT_comp_dir" and hope that clang's directory entry 0 always matches
DW_AT_comp_dir...

[Bug debug/101431] gcc-generated DWARF5 .debug_line directory entries violate the DWARF5 spec

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
You've omitted the most important information, what binutils version you are
using and what binutils gcc has been configured against, because the line table
is usually (with the exception of -gno-as-loc-support etc.) created by the
assembler with the help of the compiler, not by the compiler itself.
So, depending on what binutils has the compiler been compiled against, the
.debug_line can sometimes be just DWARF 3 or 4 instead of 5 even when other
sections (the compiler emitted ones) are DWARF 5 etc.
When using binutils 2.36.1 against which gcc has been configured I certainly
see
Raw dump of debug contents of section .debug_line:

  Offset:                      0x0
  Length:                      79
  DWARF Version:               5
...
 The Directory Table (offset 0x22, lines 2, columns 1):
  Entry Name
  0     (indirect line string, offset: 0x10): /tmp
  1     (indirect line string, offset: 0x15): out

 The File Name Table (offset 0x30, lines 2, columns 2):
  Entry Dir     Name
  0     0       (indirect line string, offset: 0x19): out/test.c
  1     1       (indirect line string, offset: 0x24): test.c
and similarly for -gno-as-loc-support on gcc configured against older binutils.

[Bug debug/101431] gcc-generated DWARF5 .debug_line directory entries violate the DWARF5 spec

[roc at ocallahan dot org]

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

--- Comment #3 from roc at ocallahan dot org <roc at ocallahan dot org> ---
This is the Fedora 34 package.

$ gcc --version
gcc (GCC) 11.1.1 20210531 (Red Hat 11.1.1-3)
$ rpm -qa|grep ^gcc-11
gcc-11.1.1-3.fc34.x86_64
$ rpm -qa|grep binutils-2
binutils-2.35.1-41.fc34.x86_64

[Bug debug/101431] gcc-generated DWARF5 .debug_line directory entries violate the DWARF5 spec

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
> cat tmp/t.c
void foo(int i) {}
> gcc-11 -g -o tmp/t.o tmp/t.c -c

and the DWARF ends up

 <0><c>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <d>   DW_AT_producer    : (indirect string, offset: 0x0): GNU C17 11.1.1
20210428 -mtune=generic -march=x86-64 -g
    <11>   DW_AT_language    : 29       (C11)
    <12>   DW_AT_name        : (indirect line string, offset: 0x0): tmp/t.c
    <16>   DW_AT_comp_dir    : (indirect line string, offset: 0x8): /
    <1a>   DW_AT_low_pc      : 0x0
    <22>   DW_AT_high_pc     : 0xa
    <2a>   DW_AT_stmt_list   : 0x0

...
 The Directory Table (offset 0x22, lines 2, columns 1):
  Entry Name
  0     (indirect line string, offset: 0xa): tmp
  1     (indirect line string, offset: 0xe): tmp

 The File Name Table (offset 0x30, lines 2, columns 2):
  Entry Dir     Name
  0     0       (indirect line string, offset: 0x12): tmp/t.c
  1     1       (indirect line string, offset: 0x1a): t.c

I suspect this is because of how GCC and gas together end up producing
.debug_line - we have

        .file   "t.c"
        .text
...
foo:
.LFB0:
        .file 1 "tmp/t.c"
...
        .section        .debug_line,"",@progbits
.Ldebug_line0:
        .file 0 "/" "tmp/t.c"

but this .file 0 ends up taking the place of comp-dir and it also
ends up duplicating the file entry for t.c unnecessarily.  I'm not
familiar with how the DWARF5 stuff was set up so I hope somebody
else can have a look.

Note the referenced testcase in github uses -gsplit-dwarf.

[Bug debug/101431] gcc-generated DWARF5 .debug_line directory entries violate the DWARF5 spec

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #4)
> > cat tmp/t.c
> void foo(int i) {}
> > gcc-11 -g -o tmp/t.o tmp/t.c -c
> 
> and the DWARF ends up
> 
>  <0><c>: Abbrev Number: 1 (DW_TAG_compile_unit)
>     <d>   DW_AT_producer    : (indirect string, offset: 0x0): GNU C17 11.1.1
> 20210428 -mtune=generic -march=x86-64 -g
>     <11>   DW_AT_language    : 29       (C11)
>     <12>   DW_AT_name        : (indirect line string, offset: 0x0): tmp/t.c
>     <16>   DW_AT_comp_dir    : (indirect line string, offset: 0x8): /
>     <1a>   DW_AT_low_pc      : 0x0
>     <22>   DW_AT_high_pc     : 0xa
>     <2a>   DW_AT_stmt_list   : 0x0
> 
> ...
>  The Directory Table (offset 0x22, lines 2, columns 1):
>   Entry Name
>   0     (indirect line string, offset: 0xa): tmp
>   1     (indirect line string, offset: 0xe): tmp
> 
>  The File Name Table (offset 0x30, lines 2, columns 2):
>   Entry Dir     Name
>   0     0       (indirect line string, offset: 0x12): tmp/t.c
>   1     1       (indirect line string, offset: 0x1a): t.c
> 
> I suspect this is because of how GCC and gas together end up producing
> .debug_line - we have
> 
>         .file   "t.c"
>         .text
> ...
> foo:
> .LFB0:
>         .file 1 "tmp/t.c"
> ...
>         .section        .debug_line,"",@progbits
> .Ldebug_line0:
>         .file 0 "/" "tmp/t.c"
> 
> but this .file 0 ends up taking the place of comp-dir and it also
> ends up duplicating the file entry for t.c unnecessarily.  I'm not
> familiar with how the DWARF5 stuff was set up so I hope somebody
> else can have a look.
> 
> Note the referenced testcase in github uses -gsplit-dwarf.

This was with binutils 2.36.1 and GCC configured against that.

[Bug debug/101431] gcc-generated DWARF5 .debug_line directory entries violate the DWARF5 spec

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #5)
> (In reply to Richard Biener from comment #4)
> > > cat tmp/t.c
> > void foo(int i) {}
> > > gcc-11 -g -o tmp/t.o tmp/t.c -c
> > 
> > and the DWARF ends up
> > 
> >  <0><c>: Abbrev Number: 1 (DW_TAG_compile_unit)
> >     <d>   DW_AT_producer    : (indirect string, offset: 0x0): GNU C17 11.1.1
> > 20210428 -mtune=generic -march=x86-64 -g
> >     <11>   DW_AT_language    : 29       (C11)
> >     <12>   DW_AT_name        : (indirect line string, offset: 0x0): tmp/t.c
> >     <16>   DW_AT_comp_dir    : (indirect line string, offset: 0x8): /
> >     <1a>   DW_AT_low_pc      : 0x0
> >     <22>   DW_AT_high_pc     : 0xa
> >     <2a>   DW_AT_stmt_list   : 0x0
> > 
> > ...
> >  The Directory Table (offset 0x22, lines 2, columns 1):
> >   Entry Name
> >   0     (indirect line string, offset: 0xa): tmp
> >   1     (indirect line string, offset: 0xe): tmp
> > 
> >  The File Name Table (offset 0x30, lines 2, columns 2):
> >   Entry Dir     Name
> >   0     0       (indirect line string, offset: 0x12): tmp/t.c
> >   1     1       (indirect line string, offset: 0x1a): t.c
> > 
> > I suspect this is because of how GCC and gas together end up producing
> > .debug_line - we have
> > 
> >         .file   "t.c"
> >         .text
> > ...
> > foo:
> > .LFB0:
> >         .file 1 "tmp/t.c"
> > ...
> >         .section        .debug_line,"",@progbits
> > .Ldebug_line0:
> >         .file 0 "/" "tmp/t.c"
> > 
> > but this .file 0 ends up taking the place of comp-dir and it also
> > ends up duplicating the file entry for t.c unnecessarily.  I'm not
> > familiar with how the DWARF5 stuff was set up so I hope somebody
> > else can have a look.
> > 
> > Note the referenced testcase in github uses -gsplit-dwarf.
> 
> This was with binutils 2.36.1 and GCC configured against that.

But it looks good (apart from duplicated file entry) with -gno-as-loc-support:

 The Directory Table (offset 0x22, lines 2, columns 1):
  Entry Name
  0     (indirect line string, offset: 0x10): /
  1     (indirect line string, offset: 0x0): tmp

 The File Name Table (offset 0x30, lines 2, columns 2):
  Entry Dir     Name
  0     0       (indirect line string, offset: 0x4): tmp/t.c
  1     1       (indirect line string, offset: 0xc): t.c

it looks like some configury doesn't work as expected?  The driver
passes --gdwarf-5 to the assembler.

[Bug debug/101431] gcc-generated DWARF5 .debug_line directory entries violate the DWARF5 spec

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
With -gsplit-dwarf (and without -gno-as-loc-support) I can reproduce in 11, but
not on the trunk, where it got fixed with
r12-1777-ga21dc9d1529b8a8071e36b22b6e8492fc2ce7d5a
The .file 0 emission in 11 used to be guarded with asm_outputs_debug_line_str
which is false for split dwarf.

[Bug debug/101431] gcc-generated DWARF5 .debug_line directory entries violate the DWARF5 spec

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> With -gsplit-dwarf (and without -gno-as-loc-support) I can reproduce in 11,
> but not on the trunk, where it got fixed with
> r12-1777-ga21dc9d1529b8a8071e36b22b6e8492fc2ce7d5a
> The .file 0 emission in 11 used to be guarded with asm_outputs_debug_line_str
> which is false for split dwarf.

r12-1777-ga21dc9d1529b8a8071e36b22b6e8492fc2ce7d5a has been backported onto the
11 branch as r11-8650-gf19b20de1b24d6b53479c6815316a5201b22775d.

[Bug debug/101431] gcc-generated DWARF5 .debug_line directory entries violate the DWARF5 spec

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Then this looks fixed to me...