[Bug debug/99178] Emit .debug_names

["tromey at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99178

--- Comment #5 from Tom Tromey <tromey at gcc dot gnu.org> ---
(In reply to David Blaikie from comment #4)

I don't remember filing this bug.  At the time maybe I thought it
would be worthwhile to have "end to end" .debug_names generation,
that is, to try to have the index and also not slow down
compilation or link times too much.  Not sure how I feel about it now.

> It'd be great to get GCC/GDB folks take on the name tables - get some
> practical experience with their contents, file any bugs about missing
> elements, etc. It's possible they're leaning too heavily towards lldb's
> style of name lookup since they derived from an existing apple
> implementation there & it'd be good to generalize them where needed.

gdb has long done the wrong thing with .debug_names.
https://sourceware.org/bugzilla/show_bug.cgi?id=24820

I don't really know how/why that happened.  However, I wrote patches to
fix it:

https://sourceware.org/pipermail/gdb-patches/2023-December/204949.html

This version of gdb will look at the augmentation string and only
allow certain indexes to be used.  This is done to avoid known bugs --
mainly coming from the "old" (current) gdb, but also clang has some
issues (from memory, it doesn't include parent info).  Also, gdb relies
on its extensions (see below).

When writing the new scanner, I found a few bugs in DWARF related to
which names appear in the index.  I don't recall offhand what these are,
and I didn't file them due to the late unpleasantness (sorry).  They
could probably be dug up by reading the scanner and comparing to the spec.

gdb will also emit some extensions.  You can see these in the docs patch:

https://sourceware.org/pipermail/gdb-patches/2023-December/204947.html

Generally the goal of these is to avoid having to do any DIE reading
in order to reject a lookup.  Note that this means gdb relies on
template parameters being in the name -- something we discussed in
gdb bugzilla a bit.

With these patches, gdb will not generate or use the hash table.
This is explained here:

https://sourceware.org/pipermail/gdb-patches/2023-December/204963.html

The only other thing I can think of offhand is that the reliance on
.debug_str means that gdb may have to augment the string table when
DW_FORM_string is in use.  This is also caused by the "(anonymous namespace)"
special case.