The .debug_names section defines a "Hash Lookup Table": ... The hash lookup table is actually two separate arrays: - an array of buckets, followed immediately by - an array of hashes. The number of entries in the buckets array is given by bucket_count, and the number of entries in the hashes array is given by name_count. ... According to the standard, the "Hash Lookup Table" is an optional part of .debug_names. Presumably, a .debug_names section without a "Hash Lookup Table" is characterized by bucket_count == 0, but not by name_count == 0, since name_count means an empty index. Gdb however has this code: ... /* Hash Lookup Table */ map.bucket_table_reordered = reinterpret_cast<const uint32_t *> (addr); addr += map.bucket_count * 4; map.hash_table_reordered = reinterpret_cast<const uint32_t *> (addr); addr += map.name_count * 4; ... So, it expects to read the hash_table, even if bucket_count is 0. This patch fixes that: ... diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c index eba5ee7897..80cbcc6c78 100644 --- a/gdb/dwarf2/read.c +++ b/gdb/dwarf2/read.c @@ -4952,8 +4952,13 @@ read_debug_names_from_section (struct objfile *objfile, /* Hash Lookup Table */ map.bucket_table_reordered = reinterpret_cast<const uint32_t *> (addr); addr += map.bucket_count * 4; - map.hash_table_reordered = reinterpret_cast<const uint32_t *> (addr); - addr += map.name_count * 4; + if (map.bucket_count > 0) + { + map.hash_table_reordered = reinterpret_cast<const uint32_t *> (addr); + addr += map.name_count * 4; + } + else + map.hash_table_reordered = nullptr; /* Name Table */ map.name_table_string_offs_reordered = addr; ... but then we run into a SIGFPE in dw2_debug_names_iterator::find_vec_in_debug_names here: ... uint32_t namei = extract_unsigned_integer (reinterpret_cast<const gdb_byte *> (map.bucket_table_reordered + (full_hash % map.bucket_count)), 4, map.dwarf5_byte_order); ... because map.bucket_count == 0, so we're dividing by zero.
My .debug_names series will fix this as well.
The master branch has been updated by Tom Tromey <tromey@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=3a862152958a1d17742cef7fc43c4d51dd2dcbab commit 3a862152958a1d17742cef7fc43c4d51dd2dcbab Author: Tom Tromey <tom@tromey.com> Date: Mon Dec 4 07:58:48 2023 -0700 Empty hash table fix in .debug_names reader The handling of an empty hash table in the .debug_names reader is slightly wrong. Currently the code assumes there is always an array of hashes. However, section 6.1.1.4.5 Hash Lookup Table says: The optional hash lookup table immediately follows the list of type signatures. and then: The hash lookup table is actually two separate arrays: an array of buckets, followed immediately by an array of hashes. My reading of this is that the hash table as a whole is optional, and so the hashes will not exist in this case. (This also makes sense because the hashes are not useful without the buckets anyway.) Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25950
The master branch has been updated by Tom Tromey <tromey@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b371f07c47c73d9597f74f87bc6e22ba04db1963 commit b371f07c47c73d9597f74f87bc6e22ba04db1963 Author: Tom Tromey <tom@tromey.com> Date: Sat Dec 2 13:18:13 2023 -0700 Rewrite .debug_names reader This rewrites the .debug_names reader to follow the spec. Since it was first written, gdb's .debug_names writer has been incorrect -- while the form of the section has been ok, the contents have been very gdb-specific. This patch fixes the reader side of this equation, rewriting the reader to create a cooked index internally -- an important detail because it allows for the deletion of a lot of code, and it means the various readers will agree more often. This reader checks for a new augmentation string. For the time being, all other producers are ignored -- the old GDB ones because they are wrong, and clang because it does not emit DW_IDX_parent. (If there are any other producers, I'm unaware of them.) While the new reader mostly runs in a worker thread, it does not try to distribute its work. This could be done by partitioning the name table. The parent computations could also be done in parallel after all names have been read. I haven't attempted this. Note that this patch temporarily regresses gdb.base/gdb-index-err.exp. This test writes an index using gdb -- but at this particular stage, gdb cannot read the indexes it creates. Rather than merge the patches into a mega-patch, I've chosen to just accept this temporary regression. In v1 of this patch, I made the new reader more strict about requiring .debug_aranges. In v2, I've backed this out and kept the previous logic. This solved a few test failures, though it's arguably not the right approach. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25950
Fixed.