From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id JLeRH1wtjmlmQTgAWB0awg (envelope-from ) for ; Thu, 12 Feb 2026 14:43:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1770925404; bh=nxYuyDKgTmq2hZYn7mV/KQG/skkL4MTjlnkdBCDktKE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=egM5TT7sBrd5EiaCvaGT3TA2N8Akk/RkP5+pMbzb0VtvsV30UMCLO8ck4pNwPvZwz nX0Ub+kVuz7li1Ht/1ffSu9nKl7S2AcT59jn5tkYihaHsWaW1TfKH/Pj5GgRDDIPVS TrR+lceFn7ks9TUWAhdBnb5pu2NlyArZHh1LlPqA= Received: by simark.ca (Postfix, from userid 112) id 4916D1E0BA; Thu, 12 Feb 2026 14:43:24 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.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,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham 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=YkEztEWW; dkim-atps=neutral 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 6F9231E08D for ; Thu, 12 Feb 2026 14:43:23 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 293F04BA23F1 for ; Thu, 12 Feb 2026 19:43:22 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 293F04BA23F1 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=YkEztEWW Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 3E0094BA2E12 for ; Thu, 12 Feb 2026 19:39:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3E0094BA2E12 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 3E0094BA2E12 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=1770925178; cv=none; b=uggiajkpr6keTA89ZcLYPUSxnmWV02UwEBIW6hEFUUceZy+9a1hS1UrjMiYQ2XsI28nOIrhoVfMO4IEn8HKjCRMCkV76X/yRIag4bFeUy1k+stGuF4ZHzA8iCQ+KisVeXfZePrjiIovTe/ZfriY7t1DIbzMjwZH5dsvl3vAlG9U= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1770925178; c=relaxed/simple; bh=nxYuyDKgTmq2hZYn7mV/KQG/skkL4MTjlnkdBCDktKE=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=UntwnkDUiMZIEow/EInWUVPPnsRXA0KnqPXMomlNk5H8xn1CvcK0i2zimMFWYJLJ1FqUZN4R08Ttz5l9yJNVCWL7XLZ40mAKaGOgb/5shAJJ/Sw/Mh5QXwVwfCUioAQ4eWinY9LVtMMJjS9AGzkVQeIBdS/aifAovg7bF1exCMk= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3E0094BA2E12 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1770925177; bh=nxYuyDKgTmq2hZYn7mV/KQG/skkL4MTjlnkdBCDktKE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=YkEztEWWCjrpWeHrlLOspKzqkK6FVjHKhLwodJfAXkvecDImH/my/Dn7dnuarfNWV Mn6FHfMJ6F2fkp0JS/ApiewVAquzw/Im/xZvmWMIOn9y3CpXEWfXqQc41Axz5o2HJa S3GGkQmfek6j4GnIZRCTaLB/br1OAgzNJtg2J2YY= Received: by simark.ca (Postfix) id 5D9FB1E08D; Thu, 12 Feb 2026 14:39:37 -0500 (EST) Message-ID: <945d83fc-5518-4e04-8fe8-ebcca0acf0bd@simark.ca> Date: Thu, 12 Feb 2026 14:39:36 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RFC 1/2] Remove "readnow" support To: Andrew Burgess , Eli Zaretskii , Tom Tromey Cc: gdb-patches@sourceware.org References: <20260211-nuke-readnow-v1-0-7eed7148eec6@tromey.com> <20260211-nuke-readnow-v1-1-7eed7148eec6@tromey.com> <86qzqqtn80.fsf@gnu.org> <87h5rmay3z.fsf@redhat.com> Content-Language: fr From: Simon Marchi In-Reply-To: <87h5rmay3z.fsf@redhat.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 2/12/26 8:29 AM, Andrew Burgess wrote: > Eli Zaretskii writes: > >>> From: Tom Tromey >>> Date: Wed, 11 Feb 2026 11:49:09 -0700 >>> Cc: Tom Tromey >>> >>> I think the "readnow" feature should be removed. >>> >>> "readnow" exists basically to work around potential bugs in any >>> "partial" reader. This used to work ok because gdb would scan all the >>> expanded symtabs in addition to using the "quick" functions. This >>> changed with the "search via psyms" series. >>> >>> So now, "readnow" is basically its own separate implementation. As >>> such, I don't think it carries its weight. It is very slow and uses a >>> lot of memory, and can have its own bugs requiring extra work on our >>> part. >> >> Is there any other way for the user to force GDB to read all of the >> symbols from all of the object files? If not, perhaps this >> functionality still has its value? Maybe we should make it a "maint" >> command instead? > > I second this. We do run into bugs with the indexes from time to time, > and it's good to have some way to tell GDB to go read the full debug > information so we can narrow the bug down. Plus it offers a work around > in these cases. > > Is 'maint expand-symtabs' the equivalent? When someone uses -readnow > should we maybe guide them towards the new way of doing things, even all > we do is point towards a particular entry in the manual maybe? >From what I understand, "maint expand-symtabs" is not an exact replacement for readnow. With the recent changes that Tom Tromey did (always search via the "quick" functions), this is how it works when searching for a symbol: - the code invokes the quick_symbol_functions::search method (cooked_index_functions::search for the DWARF index). - if a compunit_symtab looks like it could contain said symbol, the quick functions' search method calls a callback, passing the compunit_symtab, and the core searches it - if you "maint expand-symtabs" first, the search still goes through cooked_index_functions::search. So if there is a bug in cooked_index_functions::search, it won't bypass it. In other words, which symtabs are currently expanded should not affect a search (this was the point of the change, that was a source of bugs) With readnow, the cooked index is not built. Instead, compunit_symtab are built from the start, and readnow_functions is used instead of cooked_index_functions. readnow_functions::search goes over the all_units vector and searches all of them (I wonder if it could use expanded_symbols_functions instead...). If there was a bug in cooked_index_functions::search, then this would by pass it. I don't know if it's really worth having a completely parallel code path just in case there is a bug in the main path. That parallel code path is a source of headaches of its own. That being said, if we could indeed use expanded_symbols_functions, then keeping readnow wouldn't represent much code I think. Simon