Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Simon Marchi <simark@simark.ca>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>,
	gdb-patches@sourceware.org
Cc: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Subject: Re: [PATCH] gdb: Skip useless minsym scan in variable-only symbol searches
Date: Sat, 26 Sep 2026 00:34:06 -0400	[thread overview]
Message-ID: <70a1e0a0-97e9-45fb-94fd-16534505d96c@simark.ca> (raw)
In-Reply-To: <20260922155125.3710118-1-adhemerval.zanella@linaro.org>

On 9/22/26 11:51 AM, Adhemerval Zanella wrote:
> The symbol-listing command -symbol-info-* family goes through
> global_symbol_searcher::search, which has 3 steps:
> 
> 1. expand_symtabs (objfile, preg): make sure every compunit that could
>    contain a match is expanded.  Returns found_msymbol = true if it
>    saw a matching msymbol that has no debug info.
> 
> 2. add_matching_symbols (...): walk the compunits and collect the real
>    matches.
> 
> 3. After the loop, a minsym fallback: if found_msymbol was set, or
>    unconditionally for any variable search with no file filter, re-scan
>    msymbols and append the ones without debug info (unless the searcher
>    set exclude_minsyms).
> 
> Step 1 had two phases, first objfile::search, which uses the
> quick-symbol index to expand candidate compunits; then the pre-pass
> for every msymbol in the objfile whose name matches the regexp:
> 
> 1.1. function search: call find_compunit_symtab_for_pc (address).  This
>      consults the quick functions and can expand the compunit containing
>      that address.
> 
> 1.2. variable search: call lookup_symbol_in_objfile_from_linkage_name,
>      which does a linear scan of objfile->compunits () per lookup.  It
>      can not expand anything; its only output is setting found_msymbol
>      when the lookup fails.
> 
> So for variables the pre-pass costs 'msymbols * expanded-compunits'
> block lookups and produces exactly one bit of information (found_msymbol)
> and this dominates the command execution time.
> 
> And in step 3. these MI3 commands (search_module_symbols) calls
> spec2.set_exclude_minsyms (true), which sets !m_exclude_minsyms to false.

The phrasing "sets !m_exclude_minsyms to false" really confused me,
could you rephrase this?

> The fallback never runs (found_msymbol is ignored), making the pre-pass
> calculation not required.
> 
> The fix is make SEARCH_VAR_DOMAIN skip the pre-pass.  For variable
> searches with no filenames the fallback condition already contains
> '(m_kind & SEARCH_VAR_DOMAIN) != 0' as an unconditional alternative.
> 
> Since the pre-pass now only runs for searches that include
> SEARCH_FUNCTION_DOMAIN, the lookup_symbol_in_objfile_from_linkage_name
> branch of the conditional inside the loop is unreachable.
> 
> Also update the comments, which still described the variable lookup and
> claimed it forces symtabs to be read.  That was true when
> lookup_symbol_in_objfile_from_linkage_name was added in commit
> 422d65e705c7, but it no longer expands any symtab.
> 
> -symbol-info-module-variables --module <M> on the 2000-module benchmark
> drops from 90 s to 0.56 s cold.

Awesome.  It took me a while to convince myself that the change is
correct, and how global_symbol_searcher works in the various cases.  One
thing that was not obvious to me was that it only supports one kind of
search at a time (you can't search for variables _and_ functions in one
search), despite the use of domain_search_flags that would suggest the
opposite.  In the process I made a few patches to tweak
global_symbol_searcher to make it more readable, I'll post them after
your patch it merged.

> 
> Change-Id: I6019bcf80629f21cf6dee74d0e96fa788a70e220
> ---
>  gdb/symtab.c | 35 ++++++++++++++---------------------
>  1 file changed, 14 insertions(+), 21 deletions(-)
> 
> diff --git a/gdb/symtab.c b/gdb/symtab.c
> index 93684c14777..13824587e75 100644
> --- a/gdb/symtab.c
> +++ b/gdb/symtab.c
> @@ -4750,22 +4750,20 @@ global_symbol_searcher::expand_symtabs
>       SEARCH_GLOBAL_BLOCK | SEARCH_STATIC_BLOCK,
>       kind);
>  
> -  /* Here, we search through the minimal symbol tables for functions and
> -     variables that match, and force their symbols to be read.  This is in
> -     particular necessary for demangled variable names, which are no longer
> -     put into the partial symbol tables.  The symbol will then be found
> +  /* Here, we search through the minimal symbol tables for functions that
> +     match, and force their symbols to be read.  The symbol will then be found
>       during the scan of symtabs later.
>  
> -     For functions, find_pc_symtab should succeed if we have debug info for
> -     the function, for variables we have to call
> -     lookup_symbol_in_objfile_from_linkage_name to determine if the
> -     variable has debug info.  If the lookup fails, set found_msymbol so
> -     that we will rescan to print any matching symbols without debug info.
> -     We only search the objfile the msymbol came from, we no longer search
> -     all objfiles.  In large programs (1000s of shared libs) searching all
> -     objfiles is not worth the pain.  */
> +     The find_compunit_symtab_for_pc should succeed if we have debug info for

I would remove the "The" in this last line.

> +     the function.  If it fails, set found_msymbol so that we will rescan to
> +     print any matching symbols without debug info.  We only search the
> +     objfile the msymbol came from, we no longer search all objfiles.
> +
> +     Variables are not handled here, and looking them up does not expand any
> +     symtab.  When no file names were given the caller unconditionally rescans
> +     the minimal symbols for SEARCH_VAR_DOMAIN.  */
>    if (m_filenames.empty ()
> -      && (kind & (SEARCH_VAR_DOMAIN | SEARCH_FUNCTION_DOMAIN)) != 0)
> +      && (kind & SEARCH_FUNCTION_DOMAIN) != 0)
>      {
>        for (minimal_symbol *msymbol : objfile->msymbols ())
>  	{
> @@ -4780,18 +4778,13 @@ global_symbol_searcher::expand_symtabs
>  		  || preg->exec (msymbol->natural_name (), 0,
>  				 NULL, 0) == 0)
>  		{
> -		  /* An important side-effect of these lookup functions is
> +		  /* An important side-effect of this lookup function is
>  		     to expand the symbol table if msymbol is found, later
>  		     in the process we will add matching symbols or
>  		     msymbols to the results list, and that requires that
>  		     the symbols tables are expanded.  */
> -		  if ((kind & SEARCH_FUNCTION_DOMAIN) != 0
> -		      ? (find_compunit_symtab_for_pc
> -			 (msymbol->value_address (objfile)) == NULL)
> -		      : (lookup_symbol_in_objfile_from_linkage_name
> -			 (objfile, msymbol->linkage_name (),
> -			  SEARCH_VFT)
> -			 .symbol == NULL))
> +		  if (find_compunit_symtab_for_pc
> +			(msymbol->value_address (objfile)) == nullptr)
>  		    found_msymbol = true;

One change I had locally to help me understand what this does was to
rename found_msymbol to found_func_msymbol_without_debug_info.  Could
you rename it as part of this patch, and rename the variable in
global_symbol_searcher::search too?

LGTM with that fixed.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

And thanks Thiago for testing.

Simon

      parent reply	other threads:[~2026-09-26  4:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-22 15:51 Adhemerval Zanella
2026-09-23 21:47 ` Thiago Jung Bauermann
2026-09-26  4:34 ` Simon Marchi [this message]

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=70a1e0a0-97e9-45fb-94fd-16534505d96c@simark.ca \
    --to=simark@simark.ca \
    --cc=adhemerval.zanella@linaro.org \
    --cc=gdb-patches@sourceware.org \
    --cc=thiago.bauermann@linaro.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