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

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

[vries at gcc dot gnu.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.

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

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |24820
                 CC|                            |tromey at sourceware dot org
           Assignee|unassigned at sourceware dot org   |tromey at sourceware dot org

--- Comment #1 from Tom Tromey <tromey at sourceware dot org> ---
My .debug_names series will fix this as well.


Referenced Bugs:

https://sourceware.org/bugzilla/show_bug.cgi?id=24820
[Bug 24820] .debug_names has incorrect contents
-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
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

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

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
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

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

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

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25950
Bug 25950 depends on bug 24820, which changed state.

Bug 24820 Summary: .debug_names has incorrect contents
https://sourceware.org/bugzilla/show_bug.cgi?id=24820

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

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

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

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |15.1
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #4 from Tom Tromey <tromey at sourceware dot org> ---
Fixed.

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