[gdb/symtab] Fix incomplete CU list assert in .debug_names
authorTom de Vries <tdevries@suse.de>
Mon, 11 May 2020 13:03:54 +0000 (15:03 +0200)
committerTom de Vries <tdevries@suse.de>
Mon, 11 May 2020 13:03:54 +0000 (15:03 +0200)
commit3ee6bb113afd87a408dd8551768d801d04556ffd
tree1ac50c4cd4a53134da0db04d0e45ed1f21160695
parent3b646889b0f71fda1e46bde8206d4d6aba7f5387
[gdb/symtab] Fix incomplete CU list assert in .debug_names

Consider the following two-file test-case:
...
$ cat main.c
extern int foo (void);

int
main (void)
{
  int sum, a, b;
  sum = a + b + foo ();
  return sum;
}
$ cat foo.c
int
foo (void)
{
  return 3;
}
...

Compiled like this:
...
$ clang-10 -gdwarf-5 -gpubnames -c main.c
$ clang-10 -gdwarf-5 -c foo.c
$ clang-10 -gdwarf-5 -gpubnames main.o foo.o
...

When loading this exec into gdb, we run into this assert:
...
$ gdb a.out
Reading symbols from a.out...

warning: Section .debug_aranges in a.out entry at offset 0 \
  debug_info_offset 0 does not exists, ignoring .debug_aranges.
src/gdb/dwarf2/read.c:6949: \
  internal-error: cutu_reader::cutu_reader(dwarf2_per_cu_data*, \
                              abbrev_table*, int, bool): \
  Assertion `this_cu->length == cu->header.get_length ()' failed.
...

The problem is that the determined length of the CU:
...
(gdb) p /x this_cu->length
$4 = 0x26a
...
does not match the actual length:
...
(gdb) p /x cu->header.get_length ()
$5 = 0x59
...

The length of the CU is determined in create_cus_from_debug_names_list, and
set based on this list in the .debug_names section:
...
  Compilation Unit offsets [
    CU[0]: 0x000000c7
  ]
...
and it is assumed that this is a complete list, so the size of the CU is
calculated using the end of the .debug_section at 0x331, making it 0x331 -
0xc7 == 0x26a.

However, the CU list is not complete:
...
$ llvm-dwarfdump -debug-info a.out \
  | grep "Compile Unit" \
  | sed 's/Compile Unit.*//'
0x00000000:
0x0000002e:
0x000000a5:
0x000000c7:
0x00000120:
0x00000157:
0x0000030f:
...
In particular, because the CU for foo.c is there at 0x120 (the rest of the CUs
is due to openSUSE having debug info for various linked in objects).

Fix the assert by not assuming to know the length of CUs in
create_cus_from_debug_names_list (if the .debug_names is not produced by GDB),
and setting it to 0, and setting it later to the actual length.

Note that this does not fix the .debug_aranges warning, that's PR25969.

Build and tested on x86_64-linux, with native and debug-names.

gdb/ChangeLog:

2020-05-11  Tom de Vries  <tdevries@suse.de>

PR symtab/25941
* dwarf2/read.c (create_cus_from_debug_names_list): Initialize CUs
with length 0, if not gdb-produced.
(cutu_reader::cutu_reader): Set CU length to actual length if 0.

gdb/testsuite/ChangeLog:

2020-05-11  Tom de Vries  <tdevries@suse.de>

PR symtab/25941
* gdb.dwarf2/clang-debug-names.exp.in: New include exp file, factored
out of ...
* gdb.dwarf2/clang-debug-names.exp: ... here.
* gdb.dwarf2/clang-debug-names-2.exp: New file.  Include
clang-debug-names.exp.in.
* gdb.dwarf2/clang-debug-names-2-foo.c: New test.
* gdb.dwarf2/clang-debug-names-2.c: New test.
gdb/ChangeLog
gdb/dwarf2/read.c
gdb/testsuite/ChangeLog
gdb/testsuite/gdb.dwarf2/clang-debug-names-2-foo.c [new file with mode: 0644]
gdb/testsuite/gdb.dwarf2/clang-debug-names-2.c [new file with mode: 0644]
gdb/testsuite/gdb.dwarf2/clang-debug-names-2.exp [new file with mode: 0644]
gdb/testsuite/gdb.dwarf2/clang-debug-names.exp
gdb/testsuite/gdb.dwarf2/clang-debug-names.exp.in [new file with mode: 0644]