From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id uffRI/i9u2oknhcAWB0awg (envelope-from ) for ; Tue, 29 Sep 2026 09:32:40 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256 header.s=google header.b=ALsEX934; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 8655A1E06B; Tue, 29 Sep 2026 09:32:40 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=unavailable autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::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 AC2471E01F for ; Tue, 29 Sep 2026 09:32:38 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5E6444BB3BD4 for ; Tue, 29 Sep 2026 13:32:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5E6444BB3BD4 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256 header.s=google header.b=ALsEX934 Received: from mail-yx2-x0d.google.com (mail-yx2-x0d.google.com [IPv6:2607:f8b0:4864:41::d]) by sourceware.org (Postfix) with ESMTPS id 276534BB3BDB for ; Tue, 29 Sep 2026 13:32:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 276534BB3BDB Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 276534BB3BDB Authentication-Results: sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:41::d ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1790688729; cv=none; b=nujyScSr1edmJPZjEQJgYJffUTKZmQ3tGmCKXuVfVNlupP22KpbmHnG4HnFIaFl1OtGpUWz/QXIMbd6vYHNcEDh92TmAqWOfgAYygGmtCZYXPxjDLHjbsy0rQs8im3kc4XVFdkh5F2Hl4yoEXtDK/ioG1iBu9UAw1VQ92v7DSho= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1790688729; c=relaxed/simple; bh=HHJSPm4xhezC2Ul+Xd/kb5L0Yq5ZQvg3b9/D2eVWZZs=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=Em/8XbPJrVAgZ6NRsrgaJgHd8pCDxLuNOz4f/sk7DZuUrOD4NGNo0NC4IvRO/p9ozsvv2xgtUI0LlDowV9im6PZZqpuEbnvgNIKhgNkVMjsCImj4hvZbzi+OdBmkF4Q/0RSlAkh40utNUuvHFll4jD5JRC2ViUnbk3PZefruSUI= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256 header.s=google header.b=ALsEX934 DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 276534BB3BDB Received: by mail-yx2-x0d.google.com with SMTP id 00721157ae682-8ab4c9f876bso2218657b3.2 for ; Tue, 29 Sep 2026 06:32:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1790688728; x=1791293528; darn=sourceware.org; h=content-transfer-encoding:content-type:in-reply-to:organization :from:content-language:references:cc:to:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=YbcY99/sg4za+vQYlunCqPWBeJxsuduYEeQxKf724JU=; b=ALsEX934wO1KRhKtsfDryCyxlvu2tMjv16U11N/m4MWDSr+kVUHOJoIYMOCW1wpvDK vxMaP7lKIZlHDr7ft8CRqDdnNT/MhG80npsXtdJLNoFBwUqlQMJak8tHbL3Zq4t9npO6 HtoSuArf+esUrqMK9LN3AIKPON6OPsgAIjIJfFTfQ7prSZ6hqUcGuabKM/mJAwZeFnr/ tiF8hb0vj9ag4w54oStmk9E7AB5qKpRQa3SwGDeelwOoAfxKrbh/l2BK8c1aXP4YLk3S DRdYZMJbWHiIfMJAecJi0dXi/4Zlop+88L0zWV0gPCP0YyQaMTI3ghZlZqehjiGwkP60 5TBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790688728; x=1791293528; h=content-transfer-encoding:content-type:in-reply-to:organization :from:content-language:references:cc:to:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=YbcY99/sg4za+vQYlunCqPWBeJxsuduYEeQxKf724JU=; b=RxjnuG+xXtQ9Ss6mYJTp70Xd+Ifk6dO8O+0PszTTni6A+J3bJxYeG6Nl7B+G1KLfUS pmRwcLdA0qxcW9Hlpc89nDfhv83mlJcgLMvpoXIekAMfH/5iwncesx5eI7EiFAIqrM+b kdW/pjsyRU0cLTqWjlLr3+LgyuH+6mOcRVKd7bq82wsbx/dw6ezUko0bU7V8NRkRFAF5 RlBnyjpeRjnz0PBO8BKvYDr2k+2L+H8G6wZxZCr5MjHBcKCqGgFi8C04nyU/Go9ix/tM KXB8Gm72iassMcZ1WvLtuN6B5tlfUUFYD7VDU8+CqBdDzpbuTWPLA1scQ5/DI39lCmdt LN8g== X-Forwarded-Encrypted: i=1; AKwUvBwEJusIVW7RsPc4w6S59FUwZgrRxA7rDxH/BPSpmwLvQtDknArZJMPO06UTvgV/iq3utI56gvJ4ePgb5g==@sourceware.org X-Gm-Message-State: AFq9FYJ6S6No0goGJMhoY0HkEwXS7FQGGLpH7krLn4A1a+DYeptGo4qg EnPvNHOk12TVRjYZK2kbdrAnTH14SuCTj22z/0lBy56ogjhD8c6Wt0VIA4JELD3PlzPul6ba6lS vp7Pj X-Gm-Gg: AYBFou38Bfoe31JtEIu3XxFqptDHViGEO/xlueH2BqvTcavBAgrciTG8boMMTWGG2Do NOqz7p24NQZin4KvJ9BUWR1bttISUsbMiOslPJh9ckMeZAchpVse6Axy41FoGNcYHcriIZOxEHC GpHWviLRzLnpy3JXMClBBU5qjQi3QNQa1YdnhIki1B2vMHXmY9i9w2PoS4ZQ1ky8CjMHdY8Bb5q OdK4LiV4W4iM4Y4mBsO8n38xcPcTMQfkTbE9LdjjgU/Bgpn4QfPjOm1925w9Tr4LgbiKI5nryi4 WbRFraEDPJEYwVbFKWzLsz6183KTuyZ78XRVX28wvbnF0VPlOQpJBgVccvAq1YAF7rakwb3kxBG 3d2vZriI4WbAMN4A3Mo37dzFA3TM5mFbn1Ub/xpzuu/9GUPyoDKg1Nd3Jup2ImoUyHuizIpg8aW 4ELlcIQ8RB5rY6yrAWzVnLQaw84JM8gzOu5gVhWNbna9Wj0HvMYVrYLSx9+52sXYbRUtj5fxTos ekyy8ZOQ2Fpkpz5ifR5CRuo6o9KNs2jx55XYMA04A2z9+phMfRzKHmv90xVVB/V/m/jxV1E4w2I 3Ji6vbjXsiUOKyde8T8AdfTjNoEZT2A= X-Received: by 2002:a05:690c:5:b0:8a1:2b39:c0a0 with SMTP id 00721157ae682-8a64af3ed9fmr96242547b3.12.1790688728118; Tue, 29 Sep 2026 06:32:08 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c1:43a:3d77:69c:1bcd:27bc? ([2804:1b3:a7c1:43a:3d77:69c:1bcd:27bc]) by smtp.gmail.com with ESMTPSA id 00721157ae682-8a860f85e57sm58297057b3.19.2026.09.29.06.32.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Sep 2026 06:32:07 -0700 (PDT) Message-ID: <75d35221-7a84-4aa8-8e67-570e5e90c544@linaro.org> Date: Tue, 29 Sep 2026 10:32:04 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb: Skip useless minsym scan in variable-only symbol searches To: Simon Marchi , gdb-patches@sourceware.org Cc: Thiago Jung Bauermann References: <20260922155125.3710118-1-adhemerval.zanella@linaro.org> <70a1e0a0-97e9-45fb-94fd-16534505d96c@simark.ca> Content-Language: en-US From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <70a1e0a0-97e9-45fb-94fd-16534505d96c@simark.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 On 26/09/26 01:34, Simon Marchi wrote: > 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? Ack, I changed to: In step 3, the fallback condition also requires '!m_exclude_minsyms'. The MI commands that go through search_module_symbols call spec2.set_exclude_minsyms (true), so for them the fallback never runs. The value of found_msymbol is then ignored and the pre-pass work is wasted. > >> 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 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. Ack. > >> >> 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. Ack. > >> + 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? Ack, I replaced 'found_msymbol' with 'found_func_msymbol_without_debug_info' on both places. > > LGTM with that fixed. > > Approved-By: Simon Marchi May I assume that I could push the patch with the above fixes? Thanks for the review. > > And thanks Thiago for testing. > > Simon