Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


  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