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.
