[Bug symtab/25950] New: [debug-names] Handle no "Hash Lookup Table"

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

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.