From: Jan Vrany <jan.vrany@labware.com>
To: gdb-patches@sourceware.org
Cc: Jan Vrany <jan.vrany@labware.com>
Subject: [PATCH 3/7] gdb: simplify find_compunit_symtab_for_pc_sect
Date: Thu, 19 Feb 2026 18:56:34 +0000 [thread overview]
Message-ID: <20260219185638.360694-4-jan.vrany@labware.com> (raw)
In-Reply-To: <20260219185638.360694-1-jan.vrany@labware.com>
This commit simplifies find_compunit_symtab_for_pc_sect by removing the
code that walks over all (currently expanded) CUs and delegating to
quick_symbol_functions::find_pc_sect_compunit_symtab instead.
With this commit on Linux x86_64 I see no regression. With -readnow
there are some regressions, mainly caused by slightly different order
of expanding CUs. Since there's a proposal to remove -readnow support,
I have not fixed nor investigated failing tests in depth.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33829
---
gdb/dwarf2/read.c | 8 -----
gdb/symtab.c | 91 -----------------------------------------------
2 files changed, 99 deletions(-)
diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index 702dca8e5e9..35046439235 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -2156,17 +2156,9 @@ dwarf2_base_index_functions::find_pc_sect_compunit_symtab
if (data == nullptr)
return nullptr;
- if (warn_if_readin && per_objfile->symtab_set_p (data))
- warning (_("(Internal error: pc %s in read in CU, but not in symtab.)"),
- paddress (objfile->arch (), pc));
-
compunit_symtab *result = find_pc_sect_compunit_symtab_includes
(dw2_instantiate_symtab (data, per_objfile, false), pc);
- if (warn_if_readin && result == nullptr)
- warning (_("(Error: pc %s in address map, but not in symtab.)"),
- paddress (objfile->arch (), pc));
-
return result;
}
diff --git a/gdb/symtab.c b/gdb/symtab.c
index cd3bf876551..4eea86319f8 100644
--- a/gdb/symtab.c
+++ b/gdb/symtab.c
@@ -2742,9 +2742,6 @@ iterate_over_symbols (const struct block *block,
struct compunit_symtab *
find_compunit_symtab_for_pc_sect (CORE_ADDR pc, struct obj_section *section)
{
- struct compunit_symtab *best_cust = NULL;
- CORE_ADDR best_cust_range = 0;
-
/* If we know that this is not a text address, return failure. This is
necessary because we loop based on the block's high and low code
addresses, which do not include the data ranges, and because
@@ -2755,94 +2752,6 @@ find_compunit_symtab_for_pc_sect (CORE_ADDR pc, struct obj_section *section)
if (msymbol.minsym && msymbol.minsym->data_p ())
return NULL;
- /* Search all symtabs for the one whose file contains our address, and which
- is the smallest of all the ones containing the address. This is designed
- to deal with a case like symtab a is at 0x1000-0x2000 and 0x3000-0x4000
- and symtab b is at 0x2000-0x3000. So the GLOBAL_BLOCK for a is from
- 0x1000-0x4000, but for address 0x2345 we want to return symtab b.
-
- This happens for native ecoff format, where code from included files
- gets its own symtab. The symtab for the included file should have
- been read in already via the dependency mechanism.
- It might be swifter to create several symtabs with the same name
- like xcoff does (I'm not sure).
-
- It also happens for objfiles that have their functions reordered.
- For these, the symtab we are looking for is not necessarily read in. */
-
- for (objfile &obj_file : current_program_space->objfiles ())
- {
- for (compunit_symtab &cust : obj_file.compunits ())
- {
- const struct blockvector *bv = cust.blockvector ();
- const struct block *global_block = bv->global_block ();
- CORE_ADDR start = global_block->start ();
- CORE_ADDR end = global_block->end ();
- bool in_range_p = start <= pc && pc < end;
- if (!in_range_p)
- continue;
-
- if (bv->map () != nullptr)
- {
- if (bv->map ()->find (pc) == nullptr)
- continue;
-
- return &cust;
- }
-
- CORE_ADDR range = end - start;
- if (best_cust != nullptr
- && range >= best_cust_range)
- /* Cust doesn't have a smaller range than best_cust, skip it. */
- continue;
-
- /* For an objfile that has its functions reordered,
- find_pc_psymtab will find the proper partial symbol table
- and we simply return its corresponding symtab. */
- /* In order to better support objfiles that contain both
- stabs and coff debugging info, we continue on if a psymtab
- can't be found. */
- struct compunit_symtab *result
- = obj_file.find_pc_sect_compunit_symtab (msymbol, pc,
- section, 0);
- if (result != nullptr)
- return result;
-
- if (section != 0)
- {
- struct symbol *found_sym = nullptr;
-
- for (int b_index = GLOBAL_BLOCK;
- b_index <= STATIC_BLOCK && found_sym == nullptr;
- ++b_index)
- {
- const struct block *b = bv->block (b_index);
- for (struct symbol *sym : block_iterator_range (b))
- {
- if (matching_obj_sections (sym->obj_section (&obj_file),
- section))
- {
- found_sym = sym;
- break;
- }
- }
- }
- if (found_sym == nullptr)
- continue; /* No symbol in this symtab matches
- section. */
- }
-
- /* Cust is best found so far, save it. */
- best_cust = &cust;
- best_cust_range = range;
- }
- }
-
- if (best_cust != NULL)
- return best_cust;
-
- /* Not found in symtabs, search the "quick" symtabs (e.g. psymtabs). */
-
for (objfile &objf : current_program_space->objfiles ())
{
struct compunit_symtab *result
--
2.51.0
next prev parent reply other threads:[~2026-02-19 19:00 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-19 18:56 [PATCH 0/7] Remove addrmap from blockvector Jan Vrany
2026-02-19 18:56 ` [PATCH 1/7] gdb: implement readnow_functions::find_pc_sect_compunit_symtab Jan Vrany
2026-02-19 20:01 ` Tom Tromey
2026-02-20 12:36 ` Jan Vraný
2026-02-20 14:25 ` Tom Tromey
2026-02-20 15:57 ` Jan Vraný
2026-02-19 18:56 ` [PATCH 2/7] gdb: update expanded_symbols_functions::find_pc_sect_compunit_symtab Jan Vrany
2026-02-19 20:02 ` Tom Tromey
2026-02-19 18:56 ` Jan Vrany [this message]
2026-02-19 20:02 ` [PATCH 3/7] gdb: simplify find_compunit_symtab_for_pc_sect Tom Tromey
2026-02-20 12:40 ` Jan Vraný
2026-02-20 14:25 ` Tom Tromey
2026-02-26 15:00 ` Jan Vraný
2026-02-19 18:56 ` [PATCH 4/7] gdb: do not set blockvector address map Jan Vrany
2026-02-19 20:03 ` Tom Tromey
2026-02-20 12:42 ` Jan Vraný
2026-02-19 18:56 ` [PATCH 5/7] gdb: update blockvector::lookup to handle non-contiguous blocks Jan Vrany
2026-02-19 20:06 ` Tom Tromey
2026-02-19 20:20 ` Tom Tromey
2026-02-20 13:03 ` Jan Vraný
2026-02-20 16:38 ` Tom Tromey
2026-03-03 11:06 ` Jan Vraný
2026-03-09 15:52 ` Jan Vraný
2026-02-19 18:56 ` [PATCH 6/7] gdb: remove address map from struct blockvector Jan Vrany
2026-02-19 18:56 ` [PATCH 7/7] gdb: add unit test for blockvector::lookup of non-contiguous blocks Jan Vrany
2026-02-19 20:12 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260219185638.360694-4-jan.vrany@labware.com \
--to=jan.vrany@labware.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox