[gdb/testsuite] Add support for .debug_names in dwarf assembler
authorTom de Vries <tdevries@suse.de>
Sun, 7 Aug 2022 06:31:36 +0000 (08:31 +0200)
committerTom de Vries <tdevries@suse.de>
Sun, 7 Aug 2022 06:31:36 +0000 (08:31 +0200)
commitf4cbdf0b6857069d42477e06f0077f4c03bb4c82
tree8e25cccc31cd591bdf59119f9e2776dbe99d1f2b
parent3ba7b1551b810b9613e11889111406138f10f208
[gdb/testsuite] Add support for .debug_names in dwarf assembler

Add:
- support for a per-module .debug_names section in the dwarf assembler, and
- a test-case excercising this new functionality.

A per-module .debug_names section needs to have an entry in the CU list for
each CU in the module, which is made more difficult by two things:
- linking in other objects, which may contain additional CUs
  (typically the case on openSUSE), and
- adding dummy CUs in the dwarf assembler.
We handle this by:
- compiling with -nostartfiles (so the test-case contains _start rather than
  main), and
- disabling the dummy CU generation for the test-case.

I've kept things simple by having the test-case specify the hash value, rather
than adding that functionality in the dwarf assembler.

Also I've kept the bucket count to 1, which makes it trivial to satisfy the
requirement that "the symbol is entered into a bucket whose index is the hash
value modulo bucket_count".

The readelf dump of the .debug_names section from the test-case looks like:
...
Version 5
Augmentation string: 47 44 42 00  ("GDB")
CU table:
[  0] 0x0

TU table:

Foreign TU table:

Used 1 of 1 bucket.
Out of 2 items there are 1 bucket clashes (longest of 1 entries).

Symbol table:
[  0] #eddb6232 _start: <1> DW_TAG_subprogram DW_IDX_compile_unit=0
[  1] #0b888030 int: <2> DW_TAG_base_type DW_IDX_compile_unit=0
...

Tested on x86_64-linux.
gdb/testsuite/gdb.dwarf2/_start.c [new file with mode: 0644]
gdb/testsuite/gdb.dwarf2/debug-names.exp [new file with mode: 0644]
gdb/testsuite/lib/dwarf.exp