From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id O17JFDsNCWhjowEAWB0awg (envelope-from ) for ; Wed, 23 Apr 2025 11:54:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1745423675; bh=awm+MEMzWDWjUCY6rhhueU0H00vFPoNn/wXKD+f8r2k=; h=Date:Subject:To:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=iSQW7xBDI+V84w2V9Fp1+uWV1Ta5YUS/wqJBIaoIEAo6SU4DTj3h9HquWZ1ZXLlMt Btcyr26dZ/oxJ59rWaF9yB4NmAzDvcunjE7glI03oPBUC2/Z/a+KZnlBhcH0YaxLHC 3xY4pIrcMcolMOOTAOQ6w8EKG7DfGPDOmWKf7CSQ= Received: by simark.ca (Postfix, from userid 112) id 3EB7E1E0C3; Wed, 23 Apr 2025 11:54:35 -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 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=Nm47yy82; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=uYfTsjSr; dkim-atps=neutral Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (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 9EACF1E0C0 for ; Wed, 23 Apr 2025 11:54:34 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 405C7385780D for ; Wed, 23 Apr 2025 15:54:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 405C7385780D Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=Nm47yy82; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=uYfTsjSr Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id EBD9D3858C41 for ; Wed, 23 Apr 2025 15:54:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EBD9D3858C41 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org EBD9D3858C41 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1745423641; cv=none; b=E0ktJH7XAHBDslJlGB1lkCAUtSYCRrFhKh8xKHyYPPAry8Rl8LKJMf3E6MAgC9a/W6VMpO3YsaYVOilLita6ZYt2jCK8UCADjd0+axyqY4kKZQkXX9KPpUM5xKlQn5BXZx8y1EPlbtc+ZlFWQtH2apmaliDu9Lh0z+YuDJJrn8A= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1745423641; c=relaxed/simple; bh=awm+MEMzWDWjUCY6rhhueU0H00vFPoNn/wXKD+f8r2k=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version: Subject:To:From; b=qDp6jjonvwTKN7d4puoPKHGPc6hLpfe0+u/c+O3QX88Ix1PBwr+J+7MKzcefjzYjMPhc1IHsCtcixFbVMMosYzqaEmFXoLoRCNAwxESGkRNhZXtaKT/XL7BCHqEil3xgO75FrT6rI8H6+I73Rsj8e8lfxrbSRiHyyYJReab/qK0= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EBD9D3858C41 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1745423639; bh=awm+MEMzWDWjUCY6rhhueU0H00vFPoNn/wXKD+f8r2k=; h=Date:Subject:To:References:From:In-Reply-To:From; b=Nm47yy82oqX+BQ41w7mtSxETM538xE1v5Z867gdqSkiLr6DGcTGMhp4Dov5GDpVhG I/+erf7YkFU9YOCxds1ApdkcO5nNEFf047uzKrM6HqyvPbUuwz3nA6kEbil+PFAtZS 3V8HZfM+KVjwH6T+kfxPWfh+y+GHgsLuMaofbAPg= Received: by simark.ca (Postfix, from userid 112) id D78521E100; Wed, 23 Apr 2025 11:53:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1745423638; bh=awm+MEMzWDWjUCY6rhhueU0H00vFPoNn/wXKD+f8r2k=; h=Date:Subject:To:References:From:In-Reply-To:From; b=uYfTsjSrjp17piHZnAOCFoX5Vq6yk/OT/cL+k7g0zRKHiVSomokXbnbjcrm9ivPmG 3yRs1u3N/sjLWZNG7if6RiugHm4yq6xuXp0giENoSiIQYQmOHbea8bOO7S2cTbh7SL bRgbPnkL43M86Gq9F18KxkQ1Jxt5PTURk+xmWUB8= Received: from [10.0.0.11] (modemcable238.237-201-24.mc.videotron.ca [24.201.237.238]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id BD2A21E0C0; Wed, 23 Apr 2025 11:53:58 -0400 (EDT) Message-ID: <2aca0e1b-6042-4839-b266-a8eb0873c21d@simark.ca> Date: Wed, 23 Apr 2025 11:53:58 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 10/28] Have expand_symtabs_matching work for already-expanded CUs To: Tom Tromey , gdb-patches@sourceware.org References: <20250402-search-in-psyms-v2-0-ea91704487cb@tromey.com> <20250402-search-in-psyms-v2-10-ea91704487cb@tromey.com> Content-Language: en-US From: Simon Marchi In-Reply-To: <20250402-search-in-psyms-v2-10-ea91704487cb@tromey.com> 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 2025-04-02 19:45, Tom Tromey wrote: > Currently, gdb will search the already-expanded symtabs in one loop, > and then also expand matching symtabs in another loop. However, this > is somewhat inefficient -- when searching the already-expanded > symtabs, all such symtabs are examined. However, the various "quick" > implementations already know which subset of symtabs might have a > match. > > This changes the contract of expand_symtabs_matching to also call the > callback for an already-expanded symtab. With this change, the number > of searched symtabs should sometimes be reduced. This also cuts down > on the amount of redundant code. Not particularly important, but I'm not sure I understand how this patch alone would result in fewer symtabs being searched. I understand that it's a step towards the ultimate goal of this series, but I suppose you need the changes to the symbol lookup functions (that come later in this series) to reduce the number of searched symtabs? I don't know if it comes later in the series, but it would be good to do some renaming, because "expand matching symtabs" is no longer accurate. It's more like "find matching symtab". That can be done later of course. > @@ -4211,6 +4223,12 @@ load_full_comp_unit (dwarf2_per_cu *this_cu, dwarf2_per_objfile *per_objfile, > if (reader.is_dummy ()) > return; > > + /* We always need the file names filled in so that > + expand_symtabs_matching can match filenames. It's convenient to > + do this here. */ > + if (!this_cu->files_read) > + dw2_get_file_names_reader (reader.cu (), reader.top_level_die ()); In other spots, this is initialized lazily when something calls dw2_get_file_names. Why would it not work with expand_symtabs_matching? Simon