RE: [PATCH] Fix macro info lookup for binaries containing DWARFv5 line table

Tomar, Sourabh Singh via Gdb-patches
2021-05-14T19:20:20Z

[AMD Public Use]

Hi Simon,

>It's not clear how you produced this output (which compiler and which command). What's the version of that section? Because it looks like a DWARF 4 or before section. GCC 10 produces a DWARF 3 >.debug_line section, even when using -gdwarf-5.
>In DWARF 4 and before, a dir_index of 0 referred to the compilation directory, even if there wasn't an explicit dir[0] value. See section 6.2.4, bullet 12, of DWARF4.pdf. So you would look up the >DW_AT_comp attribute of the compilation unit, append "macro.c", and that would give you the location of that file.

Apologies for sharing sparse details of the tools/commands.
Details: Distribution : 18.04.1-Ubuntu
GCC: rebased and **built today** i.e gcc (GCC) 12.0.0 20210514 (experimental)
Build config:
./configure --disable-bootstrap --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu CFLAGS=-O3 CXXFLAGS=-O3 --enable-languages=c,c++,fortran --prefix=/home/sourabh/install/release/trunk-gcc/
Terminal:
```
>llvm-dev>>>sourabh@llvm-slrz2:~/work/dwarf/c_c++$ tot-gcc --version
gcc (GCC) 12.0.0 20210514 (experimental)

>llvm-dev>>>sourabh@llvm-slrz2:~/work/dwarf/c_c++$ gdb --version
GNU gdb (GDB) 11.0.50.20210512-git

>llvm-dev>>>sourabh@llvm:~/work/dwarf/c_c++$ cat macro.c
#define HELLO_GDB 1
int main() {}
>llvm-dev>>>sourabh@llvm:~/work/dwarf/c_c++$ tot-gcc -gdwarf-5 -g3 macro.c -o a.out.gcc
>llvm-dev>>>sourabh@llvm:~/work/dwarf/c_c++$ gdb a.out.gcc -q
Reading symbols from a.out.gcc...
(gdb) start
Temporary breakpoint 1 at 0x40048f: file macro.c, line 2.
Starting program: /home/sourabh/work/dwarf/c_c++/a.out

Temporary breakpoint 1, main () at macro.c:2
2 int main() {}
(gdb) info macros
>>> main_file->filename -> // printf
sal.symtab->filename -> macro.c // printf
(gdb)

>llvm-dev>>>sourabh@llvm-slrz2:~/work/dwarf/c_c++$ llvm-dwarfdump --debug-line a.out.gcc
a.out.gcc: file format elf64-x86-64

.debug_line contents:
debug_line[0x00000000]
Line table prologue:
total_length: 0x00000058
format: DWARF32
**version: 2 //** Version is 2, even at -gdwarf-5 -gstrict-dwarf, is this Okay** ?
prologue_length: 0x0000003c
min_inst_length: 1
default_is_stmt: 1
line_base: -5
line_range: 14
opcode_base: 13
include_directories[ 1] = "/usr/include"
file_names[ 1]:
name: "macro.c"
dir_index: 0
mod_time: 0x00000000
length: 0x00000000
file_names[ 2]:
name: "stdc-predef.h"
dir_index: 1
mod_time: 0x00000000
length: 0x00000000
```

Please let me know if above info suffices the details necessary ?

>On my side, I see this with gcc 11 (from the Ubuntu 21.04 package):
> root@bc7daa9a3ffc:/# gcc-11 --version
> gcc-11 (Ubuntu 11.1.0-1ubuntu1~21.04) 11.1.0
> root@bc7daa9a3ffc:/# cat test.c
> #include <stdio.h>
> #define FOO
> int main() {
> }
> root@bc7daa9a3ffc:/# gcc-11 -gdwarf-5 -g3 test.c
> root@bc7daa9a3ffc:/# llvm-dwarfdump-12 --debug-line a.out
...
> include_directories[ 0] = "/usr/include"
..
> file_names[ 0]:
> name: "test.c"
> dir_index: 0
> file_names[ 1]:
> name: "test.c"
> dir_index: 0
> file_names[ 2]:
> name: "stdc-predef.h"
> dir_index: 1
> file_names[ 3]:
> name: "stdio.h"
> dir_index: 1
>So from what I see, GCC 11 generates a dir[0] entry and a file[0] entry.
>However, the dir[0] value does not look good. It makes it appear as if my source file was at /usr/include/test.c, which it wasn't (it was at /test.c).

Thanks for sharing this, since both file0 and dir0 both are present, if possible, could you please share any behavior change or anything subtle you notice before/after
applying patch ?

Thanks,
Sourabh

-----Original Message-----
From: Simon Marchi <simon.marchi@polymtl.ca>
Sent: Saturday, May 15, 2021 12:20 AM
To: Tomar, Sourabh Singh <SourabhSingh.Tomar@amd.com>; Keith Seitz <keiths@redhat.com>; gdb-patches@sourceware.org
Subject: Re: [PATCH] Fix macro info lookup for binaries containing DWARFv5 line table

[CAUTION: External Email]

> One thing I noticed that changed is that GCC is now emitting `dir0`
> entry in line table as per DWARF5. However this still seems Incomplete to me:
> $llvm-dwarfdump --debug-line a.out
> ```
> include_directories[ 1] = "/usr/include" // index still starting from `1` even at "-gdwarf-5"
> file_names[ 1]:
> name: "macro.c"
> dir_index: 0 // -> dir 0 mentioned but dir 0 is not present in list of directories, i.e index still starting from 1
> mod_time: 0x00000000
> length: 0x00000000
> file_names[ 2]:
> name: "stdc-predef.h"
> dir_index: 1
> mod_time: 0x00000000
> length: 0x00000000
> ```

It's not clear how you produced this output (which compiler and which command). What's the version of that section? Because it looks like a DWARF 4 or before section. GCC 10 produces a DWARF 3 .debug_line section, even when using -gdwarf-5.

In DWARF 4 and before, a dir_index of 0 referred to the compilation directory, even if there wasn't an explicit dir[0] value. See section 6.2.4, bullet 12, of DWARF4.pdf. So you would look up the DW_AT_comp attribute of the compilation unit, append "macro.c", and that would give you the location of that file.

On my side, I see this with gcc 11 (from the Ubuntu 21.04 package):

root@bc7daa9a3ffc:/# gcc-11 --version
gcc-11 (Ubuntu 11.1.0-1ubuntu1~21.04) 11.1.0
root@bc7daa9a3ffc:/# cat test.c
#include <stdio.h>

#define FOO

int main() {
}
root@bc7daa9a3ffc:/# gcc-11 -gdwarf-5 -g3 test.c
root@bc7daa9a3ffc:/# llvm-dwarfdump-12 --debug-line a.out
...
include_directories[ 0] = "/usr/include"
include_directories[ 1] = "/usr/include"
include_directories[ 2] = "/usr/include/x86_64-linux-gnu/bits"
include_directories[ 3] = "/usr/include/x86_64-linux-gnu/sys"
include_directories[ 4] = "/usr/include/x86_64-linux-gnu/gnu"
include_directories[ 5] = "/usr/lib/gcc/x86_64-linux-gnu/11/include"
include_directories[ 6] = "/usr/include/x86_64-linux-gnu/bits/types"
file_names[ 0]:
name: "test.c"
dir_index: 0
file_names[ 1]:
name: "test.c"
dir_index: 0
file_names[ 2]:
name: "stdc-predef.h"
dir_index: 1
file_names[ 3]:
name: "stdio.h"
dir_index: 1

So from what I see, GCC 11 generates a dir[0] entry and a file[0] entry.
However, the dir[0] value does not look good. It makes it appear as if my source file was at /usr/include/test.c, which it wasn't (it was at /test.c).

Simon