From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id deylFTYKyWrtWyAAWB0awg (envelope-from ) for ; Fri, 09 Oct 2026 11:37:26 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=XVdSBLgn; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 3ADB31E04E; Fri, 09 Oct 2026 11:37:26 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id C16DF1E04E for ; Fri, 09 Oct 2026 11:37:24 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 62BE34BA2E0D for ; Fri, 9 Oct 2026 15:37:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 62BE34BA2E0D Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=XVdSBLgn Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 6575F4BA5433 for ; Fri, 9 Oct 2026 15:36:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6575F4BA5433 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6575F4BA5433 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1791560217; cv=none; b=F7/jE1Mna3T/5OV2lBClMf/tPQyqM2ztfxjVgdnKqkckgbx/5tYnrdYPw45xsyfTR2i9R2YxcY3tLW4CleQP6gos4nN5R99+7sULPVFd+iWWz3IgK/bWTEuzVK/oOIyN+iiZeybCI00DPv7BN/RBPdSoy9CZ2x699lG0Ytrl26s= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1791560217; c=relaxed/simple; bh=4FJCviKiIbzQCsPtpKAbMURFuXLVHb/3kF0Vk7uiMVE=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=oW6tn+aqn6nZ975FUhp134P0UqJbFgyq+u0+aaf3HkEOky5oX/SZClDELKWjTVP1mKc1Ht3EoseJMAsC+EinmETdLQXB28/ol3aMNmq3hYHPXXNQovhnBD8C8ZyX2GwqY9upZUbpvCrQuNOnfP+7Xv4K6jJ8OWUvlNzMWVQztnk= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=XVdSBLgn DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6575F4BA5433 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1791560217; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=QL/d5EQSegSfubSpDS6wGeOVSyts9nmxvVc0EbWjBEI=; b=XVdSBLgnef0Af+JacZqmROcohgsSFarXpjDJAbACTYCJZL5s3yl3K5VRqS3a2GpQLlh9Yo YXgVELXhJycSHlzh4996sPktblK2GNhM35TfG+ZAySwd/iyhBvcwiLc7crhJMSnRFu/ZMv Jlo/z2QSIE5KtFTdXP6PNHcohwXMgWg= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-284-7NtqeiyMOca2ve1cR89BGQ-1; Fri, 9 Oct 2026 15:36:55 +0000 X-MC-Unique: 7NtqeiyMOca2ve1cR89BGQ-1 X-Mimecast-MFC-AGG-ID: 7NtqeiyMOca2ve1cR89BGQ_1791560214 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-48c46582442so3522021f8f.0 for ; Fri, 09 Oct 2026 08:36:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791560214; x=1792165014; h=content-type:mime-version:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=QL/d5EQSegSfubSpDS6wGeOVSyts9nmxvVc0EbWjBEI=; b=UY+vwo9l2WjDbp4s0YT9rDjCcANjrQ1dZPE3/sBs5kSp9AwXY6Mnjm0Vkb3GN8cCnL 8KpWhqZmmJlJK4OveTn92GlusHmLa1hkj2IL5Hw6/K3vcOrUoNRtK7ppLVQmTVIP7px/ 1uEvUD97NTpzbKa8nglnzvMdtO9WZcPQuQBkqfq5Y2O+WCWOQKsxuRewfDiyY/zLAPy9 81b5IGYfJI5m4/+tQkrMqj6E9E8H5MclsUCe8QFpFqOLKnvekpd9eylgMR99isuJZFD8 sJLuQgiY7ras9p87WMBQq/HkuZFsLWDI0TebVOy5MyJO6j1rQNBWYU3mDs7QCBxjz9aq s7BQ== X-Forwarded-Encrypted: i=1; AKwUvBy+pP3qjywFRSzPLWNQh6VsPM+PtvbZlwTk/pZb8a9L5TGDfp3gnYly7CVv1UIv4PCvopiH706DD3BSGw==@sourceware.org X-Gm-Message-State: AFq9FYIHQbRhQEb9A8lcHqWNpQyQH++4UhkBDDSsdN/Z6Iy/zdeqVMd+ vZypLZKBBPwsxTQ8jXdkvfkL9ITHZb6zMf+S9BcjqTNFnk9LkHjNYlDwEFAYI6doRmYkaQJEOO7 bGtD/z7eEwQ8ZJPR2PvmNG0LbL4UeOjt/2NNIG6xt9MngHiEiXftZ7RWQgCCbR8NRyandvU0= X-Gm-Gg: AYBFou1kuiAO9pYyyxYOTRsQvjPT0DSku78qDKwZlA+bbkB9A9JTw77T4XpZUQPf7LX JcDZM0TTV09J8srLQ73cOvZMWWKL+tHLmEGuP/HG/qu3shwoR+W+1Fvw28n9WC4m0+WJBEInGy5 BZxxSeT4NNpQ9MormP/Xq94fTqijV1X2LwgcVrqaMf4+/6JoCWR+qzNB6pRVUg59yqJG7CcAIJ+ dxNfRZhHok51Doh4HqpwOGV0WrtrXXcAT0PiX12CzTzRm9pI2IVEcmNLjgQOm2xsPAU/XGQfeIZ VsoPk0yn5fFxbq3EcMbk9l24QX5bfDQxmN+XraCHLuDteaW0YfIQ+i5yTWxsH7MaCdJd X-Received: by 2002:a05:6000:46c8:b0:488:8bc1:a2eb with SMTP id ffacd0b85a97d-48dba9df38dmr2678149f8f.39.1791560213956; Fri, 09 Oct 2026 08:36:53 -0700 (PDT) X-Received: by 2002:a05:6000:46c8:b0:488:8bc1:a2eb with SMTP id ffacd0b85a97d-48dba9df38dmr2678118f8f.39.1791560213411; Fri, 09 Oct 2026 08:36:53 -0700 (PDT) Received: from localhost ([213.31.44.29]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48db9aac57fsm4470048f8f.23.2026.10.09.08.36.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Oct 2026 08:36:52 -0700 (PDT) From: Andrew Burgess To: Adhemerval Zanella , gdb-patches@sourceware.org Cc: Thiago Jung Bauermann Subject: Re: [PATCH] gdb: Restrict module drill-down searches to matched modules In-Reply-To: <20261006204442.2251718-1-adhemerval.zanella@linaro.org> References: <20261006204442.2251718-1-adhemerval.zanella@linaro.org> Date: Fri, 09 Oct 2026 16:36:51 +0100 Message-ID: <87fqyeubqk.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: rvGytIITiMpcFjIMQoPsygeLDxfAAnEGqhTxg3pZaOw_1791560214 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Adhemerval Zanella writes: > search_module_symbols (used by -symbol-info-module-{functions,variables} > and the 'info module' subcommands) performs a second global_symbol_searcher > search for *all* functions or variables in the program with no module > filter. This expands every compunit, and only afterwards keeps the > symbols whose qualified name starts with a matched module prefix. > > The modules are already known from the first search, so restrict the > second one to the symbols qualified by one of them. Their names are > collected in a set, and the new global_symbol_searcher::set_scope_filter > makes the search skip every name that is not prefixed by one of them. > It is checked while expanding symtabs, so that the compunits of the > other modules are not expanded at all, and while collecting symbols > and minimal symbols. > > Handing the searcher a '^\(mod1\|mod2\|...\)::' regexp instead would > restrict the search in the same way, but gdb matches regexps with > libiberty's backtracking matcher, which tries every alternative for each > name; with a few thousand modules that costs more than the compunit > expansion it avoids. > > Also return early when no module matched, skipping the second search > entirely. > > On a 2000-module synthetic Fortran benchmark, cold medians: > > -symbol-info-module-functions --module : 0.97 s -> 0.05 s > -symbol-info-module-variables --module : 0.34 s -> 0.06 s > > with a regexp matching 100 of the modules: > > -symbol-info-module-variables --module : 0.38 s -> 0.08 s > > and the searches that match every module are not penalised: > > -symbol-info-module-variables: 1.36 s -> 1.28 s > -symbol-info-module-functions: 1.86 s -> 1.16 s > -symbol-info-module-variables --name grid_: 0.39 s -> 0.39 s > > Change-Id: I9d1554fce539f89b6d1f09802b6d24469bec49cf > --- > gdb/symtab.c | 40 +++++++++++++++++++-- > gdb/symtab.h | 22 ++++++++++-- > gdb/testsuite/gdb.fortran/info-modules.exp | 13 +++++++ > gdb/testsuite/gdb.mi/mi-fortran-modules.exp | 13 +++++++ > 4 files changed, 83 insertions(+), 5 deletions(-) > > diff --git a/gdb/symtab.c b/gdb/symtab.c > index b082a488b88..9551f3cdc74 100644 > --- a/gdb/symtab.c > +++ b/gdb/symtab.c > @@ -4783,6 +4783,9 @@ global_symbol_searcher::symbol_matches > if (!name_matches (name_regex, sym->natural_name ())) > return false; > > + if (!scope_filter_matches (sym->natural_name ())) > + return false; > + > switch (m_kind) > { > case symbol_search_kind::VARIABLE: > @@ -4826,7 +4829,25 @@ global_symbol_searcher::msymbol_matches > if (!is_suitable_msymbol (msymbol)) > return false; > > - return name_matches (name_regex, msymbol->natural_name ()); > + if (!name_matches (name_regex, msymbol->natural_name ())) > + return false; > + > + return scope_filter_matches (msymbol->natural_name ()); > +} > + > +/* See symtab.h. */ > + > +bool > +global_symbol_searcher::scope_filter_matches (const char *name) const > +{ > + if (m_scope_filter == nullptr) > + return true; > + > + const std::string_view full_name (name); > + const size_t sep = full_name.find ("::"); > + > + return (sep != std::string_view::npos > + && m_scope_filter->contains (full_name.substr (0, sep))); > } Unfortunately, I this doesn't work right now. If you take your new test and add a 'clean_restart' call before it, like this: clean_restart $testfile GDBInfoModuleSymbols::run_command "info module functions -m mod1 SUB_M1_A" GDBInfoModuleSymbols::check_header \ "All functions matching regular expression \"SUB_M1_A\", in all modules matching regular expression \"mod1\":" GDBInfoModuleSymbols::check_entry "${srcfile}" "mod1" "25" \ "void mod1::sub_m1_a\\(${integer4}\\);" GDBInfoModuleSymbols::check_no_entry "${srcfile}" ".*" GDBInfoModuleSymbols::check_no_entry "${srcfile2}" ".*" Then run, you'll find that you no longer list the expected functions. The old code would though. The problem is that the NAME passed to scoped_filter_matches is only qualified once the containing symtab has been expanded. Before then it is not qualified, and the `full_name.find ("::")` will not find the :: string and so every function symbol will be rejected. I tracked the bug down, but I've run out of time right now to think about what the solution is. But you should for sure update your tests to cover this case. > > /* See symtab.h. */ > @@ -4851,7 +4872,8 @@ global_symbol_searcher::expand_symtabs > &lookup_name_info::match_any (), > [&] (const char *symname) > { > - return name_matches (name_regex, symname); > + return (name_matches (name_regex, symname) > + && scope_filter_matches (symname)); > }, > NULL, > SEARCH_GLOBAL_BLOCK | SEARCH_STATIC_BLOCK, > @@ -6723,12 +6745,24 @@ search_module_symbols (const char *module_regexp, const char *regexp, > spec1.set_exclude_minsyms (true); > std::vector modules = spec1.search (); > > + if (modules.empty ()) > + return results; > + > /* Now search for all symbols of the required KIND matching the required > regular expressions. We figure out which ones are in which modules > - below. */ > + below. > + > + Only symbols of the modules found above can be part of the result, > + so restrict the search to them. This avoids expanding the symtabs of > + every other module. */ > + gdb::unordered_set module_names; > + for (const symbol_search &p : modules) > + module_names.insert (p.symbol->print_name ()); I think this use of `print_name` is wrong. I think `natural_name` would be the correct choice. The comment on `print_name` says: /* Returns a version of the name of a symbol that is suitable for output. In C++ this is the "demangled" form of the name if demangle is on and the "mangled" form of the name if demangle is off. In other languages this is just the symbol name. The result should never be NULL. Don't use this for internal purposes (e.g. storing in a hashtable): it's only suitable for output. */ It specifically calls out this exact use case as a place where print_name should not be used. You should be able to test this change by setting 'set print demangle off' and running your existing module lookup tests again, but that still doesn't work as there are two additional uses of `print_name` later in this function that cause this to break. It would be good if you could create a new commit, before this one, that fixes the existing bug and adds a suitable test. Then this commit would come after adding the new filter changes. Thanks, Andrew