[Bug macros/31750] New: [gdb/macros] Can't print macro with binaries built with clang -gsplit-dwarf

[Bug macros/31750] New: [gdb/macros] Can't print macro with binaries built with clang -gsplit-dwarf

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31750

            Bug ID: 31750
           Summary: [gdb/macros] Can't print macro with binaries built
                    with clang -gsplit-dwarf
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: macros
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

[ At first glance, a duplicate of PR27966, but filing anyway to record the
analysis. ] 

Consider a hello world, compiled with clang like so:
...
$ clang-15 ~/data/hello.c -gdwarf-5 -g3 -fdebug-macro -gsplit-dwarf
...

Let's try to print a predefined macro using lldb:
...
$ lldb -b a.out -o "b main" -o "run" -o "p __DBL_MAX__"
(lldb) target create "a.out"
Current executable set to '/home/vries/gcc/a.out' (x86_64).
(lldb) b main
Breakpoint 1: where = a.out`main + 15 at hello.c:6:3, address =
0x00000000000006af
(lldb) run
Process 4753 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
    frame #0: 0x00005555555546af a.out`main at hello.c:6:3
   3    int
   4    main (void)
   5    {
-> 6      printf ("hello\n");
   7      return 0;
   8    }

Process 4753 launched: '/home/vries/gcc/a.out' (x86_64)
(lldb) p __DBL_MAX__
(double) $0 = 1.7976931348623157E+308
...

OK, that works.

Now with gdb:
...
$ gdb -q -batch a.out -ex "p main" -ex "p __DBL_MAX__"
$1 = {int (void)} 0x6a0 <main>
No symbol "__DBL_MAX__" in current context.
...

Using complaints (and a gdb with this
(https://sourceware.org/pipermail/gdb-patches/2024-May/209245.html) patch
series applied to skip useless complaints), we get a bit more info:
...
$ gdb -q -iex "set complaints 100" -batch a.out -ex "p main" -ex "p
__DBL_MAX__"
During symbol reading: bad file number in macro information (2)
During symbol reading: bad file number in macro information (3)
During symbol reading: bad file number in macro information (4)
During symbol reading: bad file number in macro information (5)
During symbol reading: bad file number in macro information (6)
During symbol reading: bad file number in macro information (7)
During symbol reading: bad file number in macro information (8)
During symbol reading: bad file number in macro information (9)
During symbol reading: bad file number in macro information (10)
During symbol reading: bad file number in macro information (11)
During symbol reading: bad file number in macro information (12)
During symbol reading: bad file number in macro information (13)
During symbol reading: bad file number in macro information (7)
During symbol reading: bad file number in macro information (14)
During symbol reading: bad file number in macro information (15)
During symbol reading: bad file number in macro information (16)
During symbol reading: bad file number in macro information (17)
During symbol reading: bad file number in macro information (18)
During symbol reading: bad file number in macro information (19)
During symbol reading: bad file number in macro information (20)
During symbol reading: bad file number in macro information (21)
During symbol reading: bad file number in macro information (22)
During symbol reading: bad file number in macro information (23)
During symbol reading: bad file number in macro information (24)
$1 = {int (void)} 0x6a0 <main>
No symbol "__DBL_MAX__" in current context.
...

What happens is that the line header for the CU in the .debug_info section is
used:
...
  Compilation Unit @ offset 0xa6:
   Length:        0x24 (32-bit)
   Version:       5
   Unit Type:     DW_UT_skeleton (4)
   Abbrev Offset: 0x66
   Pointer Size:  8
   DWO ID:        0x1c8d73239b1475eb
 <0><ba>: Abbrev Number: 1 (DW_TAG_skeleton_unit)
    <bb>   DW_AT_stmt_list   : 0xe3
    <bf>   DW_AT_str_offsets_base: 0x8
    <c3>   DW_AT_comp_dir    : (indexed string: 0): /home/vries/gcc
    <c4>   DW_AT_GNU_pubnames: 1
    <c4>   DW_AT_dwo_name    : (indexed string: 0x1): hello.dwo
    <c5>   DW_AT_low_pc      : (index: 0x1): 0x6a0
    <c6>   DW_AT_high_pc     : 0x25
    <ca>   DW_AT_addr_base   : 0x8
...
which only has two entries:
...
  Offset:                      0xe3
  ...
 The Directory Table (offset 0x105, lines 2, columns 1):
  Entry Name
  0     /home/vries/gcc
  1     /home/vries

 The File Name Table (offset 0x115, lines 2, columns 3):
  Entry Dir     MD5                             Name
  0     0 0x367c7da80b57791d0afc348849013b38    /home/vries/data/hello.c
  1     1 0x367c7da80b57791d0afc348849013b38    data/hello.c
...
while the .debug_line info from the .debug_line.dwo section should be used:
...
  Offset:                      0
  ...
 The Directory Table (offset 0x16, lines 8, columns 1):
  Entry Name
  0     /home/vries/gcc
  1     /home/vries
  2     /usr/include
  3     /usr/include/bits
  4     /usr/include/sys
  5     /usr/include/gnu
  6     /usr/lib64/clang/15.0.7/include
  7     /usr/include/bits/types

 The File Name Table (offset 0xb3, lines 25, columns 3):
  Entry Dir     MD5                             Name
  0     0 0x367c7da80b57791d0afc348849013b38    /home/vries/data/hello.c
  1     1 0x367c7da80b57791d0afc348849013b38    data/hello.c
  2     2 0xd774cbf84b291e7d50e25cd3de7e915b    stdio.h
  3     3 0x9d9716682915c39863dc9872c25b610d    libc-header-start.h
  4     2 0x766938db7ce60f7257539d19e6a60737    features.h
  5     2 0x5e6e72fbda48fba969c52954f16c8ef     stdc-predef.h
  6     4 0x20212db0dcb9759a93b2ea81d4eb80b3    cdefs.h
  7     3 0x78a3de71864f7d2e0660b2e840e4f0af    wordsize.h
  8     3 0xf74a99d982dbc9823baf30acb96a33f5    long-double.h
  9     5 0x351434223df6a3054a97ba9626667cbb    stubs.h
  10    5 0xdd0ce09ec5cdb16cd6a7b59756fb5eca    stubs-64.h
  11    6 0x5612ac58ac761817cdd5356d377869b7    stddef.h
  12    6 0x82cfae8793c3e591d289b531d9cbe34d    stdarg.h
  13    3 0x90503b04519a6ee7bec6cf6d1a4b30f6    types.h
  14    3 0x885bd7aa92f5e6e0edc9b56b7281526e    timesize.h
  15    3 0x7a2cac8d0168a7319f0caa5c5463df55    typesizes.h
  16    3 0xd648a19913a5515f7bf5c96baeef3ab9    time64.h
  17    7 0xce8943aff994930a6c1a55f3da8bde32    __fpos_t.h
  18    7 0x551a470b3eed1d69e34894683e1a9182    __mbstate_t.h
  19    7 0x75edabb9a0a5ed083d12b04379e6ddc5    __fpos64_t.h
  20    7 0xb7c2c5dff3c6e7ca4a481f9890fea872    __FILE.h
  21    7 0x5ddea011defd759043423c22b69f1f57    FILE.h
  22    7 0xf4d8ea76963ae08c4408341f5670c9f3    struct_FILE.h
  23    3 0x8ac40cd538cbde0282de4c124219ef35    stdio_lim.h
  24    3 0x293b76b31b48661838e9e28ca49c1802    sys_errlist.h
...

Note btw that there's no DW_AT_stmt_list in the CU in the .debug_info.dwo
section:
...
  Compilation Unit @ offset 0:
   Length:        0x4c (32-bit)
   Version:       5
   Unit Type:     DW_UT_split_compile (5)
   Abbrev Offset: 0
   Pointer Size:  8
   DWO ID:        0x1c8d73239b1475eb
 <0><14>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <15>   DW_AT_producer    : main
    <16>   DW_AT_language    : 12       (ANSI C99)
    <18>   DW_AT_name        : int
    <19>   DW_AT_dwo_name    : clang version 15.0.7
    <1a>   DW_AT_macros      : 0
...
so I guess we're just assuming offset 0.

Same thing for dwarf4.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug macros/31750] [gdb/macros] Can't print macro with binaries built with clang -gsplit-dwarf

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31750

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #0)
> Now with gdb:
> ...
> $ gdb -q -batch a.out -ex "p main" -ex "p __DBL_MAX__"
> $1 = {int (void)} 0x6a0 <main>
> No symbol "__DBL_MAX__" in current context.
> ...

I made a mistake, this is not equivalent to the lldb scenario, I forgot start. 

So, instead we have:
...
$ gdb -q -batch a.out -ex start -ex "p __DBL_MAX__"
Temporary breakpoint 1 at 0x6af: file /home/vries/data/hello.c, line 6.

Temporary breakpoint 1, main () at /home/vries/data/hello.c:6
6         printf ("hello\n");
$1 = 1.7976931348623157e+308
...
which does work.

Anyway, we can demonstrate the problem indicated by the complaints using this
command:
...
$ gdb -q -batch a.out -ex start -ex "info macro _STDIO_H"
Temporary breakpoint 1 at 0x6af: file /home/vries/data/hello.c, line 6.

Temporary breakpoint 1, main () at /home/vries/data/hello.c:6
6         printf ("hello\n");
Defined at /home/vries/gcc/<bad macro file number 2>:24
  included at /home/vries/data/hello.c:1
#define _STDIO_H 1
...

And using this patch:
...
diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index 049ee4d52ff..dfb2c91e0d1 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -21155,6 +21155,7 @@ dwarf_decode_macros (struct dwarf2_cu *cu, unsigned int
offset,
   struct dwarf2_section_info *section;
   const char *section_name;

+  line_header_up lh_up;
   if (cu->dwo_unit != nullptr)
     {
       if (section_is_gnu)
@@ -21167,6 +21168,20 @@ dwarf_decode_macros (struct dwarf2_cu *cu, unsigned
int offset,
          section = &cu->dwo_unit->dwo_file->sections.macinfo;
          section_name = ".debug_macinfo.dwo";
        }
+
+      {
+       struct dwarf2_section_info *line_section;
+
+       line_section = &cu->dwo_unit->dwo_file->sections.line;
+       section->read (per_objfile->objfile);
+       if (section->buffer == NULL)
+         {
+           complaint (_("missing .debug_line.dwo section"));
+           return;
+         }
+       lh_up = dwarf_decode_line_header ((sect_offset)0, 0, per_objfile,
line_section, &cu->header, nullptr);
+       lh = lh_up.get ();
+      }
     }
   else
     {
...
we get instead:
...
$ gdb -q -batch a.out -ex start -ex "info macro _STDIO_H"
Temporary breakpoint 1 at 0x6af: file /home/vries/data/hello.c, line 6.

Temporary breakpoint 1, main () at /home/vries/data/hello.c:6
6         printf ("hello\n");
Defined at /usr/include/stdio.h:24
  included at /home/vries/data/hello.c:1
#define _STDIO_H 1
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug macros/31750] [gdb/macros] Can't print macro with binaries built with clang -gsplit-dwarf

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31750

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
BTW, the problem doesn't seem to happen for gcc, because we have in section
.debug_line:
...
  Offset:                      0xe3
  ...
 The Directory Table (offset 0x105, lines 8, columns 1):
  Entry Name
  0     (indirect line string, offset: 0): /home/vries/gcc
  1     (indirect line string, offset: 0x10): /home/vries/data
  2     (indirect line string, offset: 0x21): /usr/include
  3     (indirect line string, offset: 0x2e): /usr/include/bits
  4     (indirect line string, offset: 0x40): /usr/include/sys
  5     (indirect line string, offset: 0x51): /usr/include/gnu
  6     (indirect line string, offset: 0x62): /home/vries/gcc/build/gcc/include
  7     (indirect line string, offset: 0x84): /usr/include/bits/types

 The File Name Table (offset 0x12b, lines 25, columns 2):
  Entry Dir     Name
  0     1       (indirect line string, offset: 0x9c): hello.c
  1     1       (indirect line string, offset: 0x9c): hello.c
  2     2       (indirect line string, offset: 0xa4): stdc-predef.h
  3     2       (indirect line string, offset: 0xb2): stdio.h
  4     3       (indirect line string, offset: 0xba): libc-header-start.h
  5     2       (indirect line string, offset: 0xce): features.h
  6     4       (indirect line string, offset: 0xd9): cdefs.h
  7     3       (indirect line string, offset: 0xe1): wordsize.h
  8     3       (indirect line string, offset: 0xec): long-double.h
  9     5       (indirect line string, offset: 0xfa): stubs.h
  10    5       (indirect line string, offset: 0x102): stubs-64.h
  11    6       (indirect line string, offset: 0x10d): stddef.h
  12    6       (indirect line string, offset: 0x116): stdarg.h
  13    3       (indirect line string, offset: 0x11f): types.h
  14    3       (indirect line string, offset: 0x127): timesize.h
  15    3       (indirect line string, offset: 0x132): typesizes.h
  16    3       (indirect line string, offset: 0x13e): time64.h
  17    7       (indirect line string, offset: 0x147): __fpos_t.h
  18    7       (indirect line string, offset: 0x152): __mbstate_t.h
  19    7       (indirect line string, offset: 0x160): __fpos64_t.h
  20    7       (indirect line string, offset: 0x16d): __FILE.h
  21    7       (indirect line string, offset: 0x16f): FILE.h
  22    7       (indirect line string, offset: 0x176): struct_FILE.h
  23    3       (indirect line string, offset: 0x184): stdio_lim.h
  24    3       (indirect line string, offset: 0x190): sys_errlist.h
...
and in section .debug_line.dwo:
...
  Offset:                      0
  ...
 The Directory Table (offset 0x22, lines 8, columns 1):
  Entry Name
  0     /home/vries/gcc
  1     /home/vries/data
  2     /home/vries/gcc/build/gcc/include
  3     /usr/include/bits/types
  4     /usr/include/bits
  5     /usr/include/gnu
  6     /usr/include/sys
  7     /usr/include

 The File Name Table (offset 0xc4, lines 25, columns 2):
  Entry Dir     Name
  0     0       /home/vries/data/hello.c
  1     1       hello.c
  2     7       stdc-predef.h
  3     7       stdio.h
  4     4       libc-header-start.h
  5     7       features.h
  6     6       cdefs.h
  7     4       wordsize.h
  8     4       long-double.h
  9     5       stubs.h
  10    5       stubs-64.h
  11    2       stddef.h
  12    2       stdarg.h
  13    4       types.h
  14    4       timesize.h
  15    4       typesizes.h
  16    4       time64.h
  17    3       __fpos_t.h
  18    3       __mbstate_t.h
  19    3       __fpos64_t.h
  20    3       __FILE.h
  21    3       FILE.h
  22    3       struct_FILE.h
  23    4       stdio_lim.h
  24    4       sys_errlist.h
...


So, AFAICT, identical file name table.

-- 
You are receiving this mail because:
You are on the CC list for the bug.