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.
