public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug symtab/25950] New: [debug-names] Handle no "Hash Lookup Table"
@ 2020-05-08 12:40 vries at gcc dot gnu.org
  2023-12-10 15:16 ` [Bug symtab/25950] " tromey at sourceware dot org
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: vries at gcc dot gnu.org @ 2020-05-08 12:40 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=25950

            Bug ID: 25950
           Summary: [debug-names] Handle no "Hash Lookup Table"
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-01-18 20:40 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-08 12:40 [Bug symtab/25950] New: [debug-names] Handle no "Hash Lookup Table" vries at gcc dot gnu.org
2023-12-10 15:16 ` [Bug symtab/25950] " tromey at sourceware dot org
2024-01-18 20:37 ` cvs-commit at gcc dot gnu.org
2024-01-18 20:38 ` cvs-commit at gcc dot gnu.org
2024-01-18 20:38 ` tromey at sourceware dot org
2024-01-18 20:40 ` tromey at sourceware dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).