From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id kAthHF1JCWgAAQIAWB0awg (envelope-from ) for ; Wed, 23 Apr 2025 16:11:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1745439069; bh=7JMy5ozmJbrHCOEeI89Zhqj4FsbZbSOYNh+1Uej5SzM=; h=Date:Subject:To:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=kUDEzxrDvYWnZPIeoyhpNQ9wmbCKdmE5CNREJsGjullK/oe2h6cQfNygma+MXsfat 1SD84qnAl4tz/2FL4sNCRk8P2gHAcADOgNwnc1QybrYjueiFFHhfKYdiQnIEfGQQ38 6nFDiL4xvDgGXxe/8IOR5iOVuePkl2MpZy8AdPSs= Received: by simark.ca (Postfix, from userid 112) id 6F0751E0C3; Wed, 23 Apr 2025 16:11:09 -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=CmWynu+Q; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=A47C6uGl; 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 DE5D61E05C for ; Wed, 23 Apr 2025 16:11:08 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 86F3D3857836 for ; Wed, 23 Apr 2025 20:11:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 86F3D3857836 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=CmWynu+Q; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=A47C6uGl Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 57B753858D26 for ; Wed, 23 Apr 2025 20:09:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 57B753858D26 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 57B753858D26 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=1745438978; cv=none; b=BmzCkq7ZfvQQ0fh5DY2vqOWStnPgCnMJ9FhHYE13wWrRuKasvmEaWO9u4wych40AThbzm0IjlmBSr2NK5JdlKrKFCQXG88qxMn9KJxE/0yafnEMPj6hho4+8/ON+KikIwHmAHKUEgRQhp8csAqoHR962bFiXFAy08+2JwauM5Ls= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1745438978; c=relaxed/simple; bh=7JMy5ozmJbrHCOEeI89Zhqj4FsbZbSOYNh+1Uej5SzM=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version: Subject:To:From; b=iJ/w3245uT1eu1qjrwmmfiLXpa285ytPaIcGxrnNXT2rI/VF67DDx9oT10S6evhvcO6vvgtMm8LrGsjyyxVz1HLbnDrx7JRrxlei8kVY1sup2iGrEjzEMEXDL6gOuPeKjz7vlERICnUBE0XYUsAaKHpzwv4sTdpMT+BmapYRtlA= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 57B753858D26 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1745438977; bh=7JMy5ozmJbrHCOEeI89Zhqj4FsbZbSOYNh+1Uej5SzM=; h=Date:Subject:To:References:From:In-Reply-To:From; b=CmWynu+Q7Y0g2/qD40SscNSN8tIm96UqWMnlvnziKB5II/QgPywROfLNTV/2Zizfs xXNkW4IRhtkC1sNV1YJM0DfQXSw9I32boSkQCca2vCpjEiTgjIL6RFn+PkhRP6TAX2 JqbodcvQtqvP7NV4x0zOdavNv4113GCsolgM0DXM= Received: by simark.ca (Postfix, from userid 112) id EE7031E100; Wed, 23 Apr 2025 16:09:37 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1745438976; bh=7JMy5ozmJbrHCOEeI89Zhqj4FsbZbSOYNh+1Uej5SzM=; h=Date:Subject:To:References:From:In-Reply-To:From; b=A47C6uGlqldsctOez9fkbLZ6ZHUhkLy4R+q0RG3eA8n+7mhdtNHkMm2U+XM91TaNW 3rbCbqU7zEuLSoAbzzZI5GL1FpUht71I4Avly7bPOmQ3PsBAvU+kB145dB0hJdnm/1 nN5slJ6UnG66GN5lXzIhBP6oVRqgWsIO73Gxz3oA= 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 A8B141E05C; Wed, 23 Apr 2025 16:09:36 -0400 (EDT) Message-ID: <3a3d5ad7-0637-4125-b72d-91afc7982cc3@simark.ca> Date: Wed, 23 Apr 2025 16:09:35 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 00/28] Search symbols via quick API To: Tom Tromey , gdb-patches@sourceware.org References: <20250402-search-in-psyms-v2-0-ea91704487cb@tromey.com> Content-Language: en-US From: Simon Marchi In-Reply-To: <20250402-search-in-psyms-v2-0-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:44, Tom Tromey wrote: > This series changes how symbols are looked up in gdb. > > Currently, symbol lookup is done in two phases. In one phase, gdb > searches all existing symtabs for a symbol. In another phase, gdb > will call expand_symtabs_matching to expand some symtabs. > > Different spots in gdb may order these phases differently -- so some > places will expand symtabs and then search the compunits, but other > places will first search expanded symtabs and then use the > expand_symtabs_matching callback to add further results. > > This approach has a few drawbacks. > > * The double search means that some discrepancies between the indexer > and the full reader go unnoticed. This may arguably be a strength > of the approach, though frequently a carefully crafted test case can > show this as a bug. Essentially, though, some searches only work by > accident. > > * Searching all expanded symtabs means that, as a debug session drags > on, searches will examine many irrelevant symtabs. > > * In some places, the two phases use different code to perform the > actual search, meaning that the results can depend on previous CU > expansion decisions. > > * Similarly, if just a single symbol is needed, then both approaches > are bad: expand-then-search will be unnecessarily inefficient, while > search-then-expand approach means that the result depends on which > CUs happen to have already been expanded. > > This series changes all of this. Now, all symbol lookups are done via > the "quick" API, with the idea being that the final search of the > expanded symtab is done via the expand_symtabs_matching callback. > > This fixes all the issues pointed out above: > > * Only relevant symtabs are searched, because the index only considers > matching symbols. > > * Some discrepancies between the indexer and the full reader show up > as symbol lookup failures. Others (if the indexer thinks a symbol > exists but the full reader does not) will just be inefficient -- but > we could add a verifier for this. > > * Lookups are no longer dependent on symtab expansion state, because > again the indexer is pre-filtering the matches. > > Re-reading the series -- it's been in development for quite a while > and I've already landed ~20 preliminary patches -- shows that there > are still a few cleanups in here that could perhaps have gone in > separately. > > Anyway, the essential change is to make the implementations of > expand_symtabs_matching also call the callback when a symtab has > already been expanded. After this, most of the work is cleaning up > individual callers. > > This change lead to some surprising places. For example, I had to > rewrite the .gdb_index reader, because the work done for > "templates.exp" simply never worked in this mode -- and the test > obscured the problems, a classic case of lookups working by accident. > > I regression tested each patch in this series. Furthermore I > regression tested the series as a whole using the cc-with-debug-names > and cc-with-gdb-index target boards. All of this was done on x86-64 > Fedora 40. > > I think maybe I've separately submitted "Ada import functions not in > index" patch. Anyway it's part of this series now. > > Signed-off-by: Tom Tromey > --- I went over the series but not in depth. I like how it simplifies the symbol lookup functions and how it makes things less error prone. You can add: Acked-By: Simon Marchi Since it touches a lot of different code, I think you should merge it soon, to avoid having to deal with more conflicts. I also have some stuff that I will need rebase on top of this, so I would like to get to it sooner than later. Simon