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
* [Bug symtab/25950] [debug-names] Handle no "Hash Lookup Table"
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 ` tromey at sourceware dot org
2024-01-18 20:37 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: tromey at sourceware dot org @ 2023-12-10 15:16 UTC (permalink / raw)
To: gdb-prs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug symtab/25950] [debug-names] Handle no "Hash Lookup Table"
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
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-01-18 20:37 UTC (permalink / raw)
To: gdb-prs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug symtab/25950] [debug-names] Handle no "Hash Lookup Table"
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
4 siblings, 0 replies; 6+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-01-18 20:38 UTC (permalink / raw)
To: gdb-prs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug symtab/25950] [debug-names] Handle no "Hash Lookup Table"
2020-05-08 12:40 [Bug symtab/25950] New: [debug-names] Handle no "Hash Lookup Table" vries at gcc dot gnu.org
` (2 preceding siblings ...)
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
4 siblings, 0 replies; 6+ messages in thread
From: tromey at sourceware dot org @ 2024-01-18 20:38 UTC (permalink / raw)
To: gdb-prs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug symtab/25950] [debug-names] Handle no "Hash Lookup Table"
2020-05-08 12:40 [Bug symtab/25950] New: [debug-names] Handle no "Hash Lookup Table" vries at gcc dot gnu.org
` (3 preceding siblings ...)
2024-01-18 20:38 ` tromey at sourceware dot org
@ 2024-01-18 20:40 ` tromey at sourceware dot org
4 siblings, 0 replies; 6+ messages in thread
From: tromey at sourceware dot org @ 2024-01-18 20:40 UTC (permalink / raw)
To: gdb-prs
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.
^ 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).