From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id YSptHgoiCWiEwgEAWB0awg (envelope-from ) for ; Wed, 23 Apr 2025 13:23:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1745429002; bh=ZCgAilAhumx6K3savYxifC3AhpQhyqbgf+CfrKHErDE=; h=Date:Subject:To:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=vGZ+BPtX37jrRHWDx4Om2AnrwRBFq6UAJQZFVvEBL5i2I67I+aCQ2QBHu4RSfKwNi Skqq2czs72RhuM0X/4KI/83VQt2u64JfXyHX6ommPnITpJk41B2w8CtIBrZ3PbJ7k0 SWFzqzR/aoTqhqaJRava+8bQsMcP9BCZ2zEQweJc= Received: by simark.ca (Postfix, from userid 112) id 5F53A1E0C3; Wed, 23 Apr 2025 13:23:22 -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=Dc8KQo8B; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=LH+Tz+Vm; 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 15F9E1E05C for ; Wed, 23 Apr 2025 13:23:21 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A9627385770D for ; Wed, 23 Apr 2025 17:23:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A9627385770D 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=Dc8KQo8B; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=LH+Tz+Vm Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 289233857820 for ; Wed, 23 Apr 2025 17:22:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 289233857820 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 289233857820 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=1745428959; cv=none; b=BYx0RygkkPomG+I6f0EEjSXIzMh6UBqupHnDkdsRMcZhqvTkAGKG78pIe1N9xAApc9QSw104rCDJLXdfJJggkrPMZEIJGgDQYzE3dTf+JsiqliA0dByHIBU1ylYLSRuTaA44PrtHa9bP8qu647xHlH2OKXRV/ZN7rCAi2///XoU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1745428959; c=relaxed/simple; bh=ZCgAilAhumx6K3savYxifC3AhpQhyqbgf+CfrKHErDE=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version: Subject:To:From; b=n3IcZuuyA2PigCSj+s5bOfu2vCg6Snq79EJLBo1nBh8saGMSAsiWg8/2cFIuFe80/EFotiNBF0BMLen6fKgN6CWGSmz8+hWHMOY4VZleHoVzNgECR01VhAZhfahgkcSb+0taW+OPnHy3dnLVMSrQog3qWO+dMvYdtTTLuN7gbAY= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 289233857820 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1745428958; bh=ZCgAilAhumx6K3savYxifC3AhpQhyqbgf+CfrKHErDE=; h=Date:Subject:To:References:From:In-Reply-To:From; b=Dc8KQo8BdWQFpm1Ah+7BdYxaBQZ0aSdhNOraIxVckxz69hon5lqY624G2seNMk/QK hQls4rPPEzgTYyzawtXbDE+Kv7mRIO2fL/ZV1ep1rGGgmvy74MvXLh99XvsnSPlxfV TK5KS2IhoF3U8kR5LWqp56hnXfGI1YkSmhOWdiJE= Received: by simark.ca (Postfix, from userid 112) id D8FA41E0C3; Wed, 23 Apr 2025 13:22:38 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1745428957; bh=ZCgAilAhumx6K3savYxifC3AhpQhyqbgf+CfrKHErDE=; h=Date:Subject:To:References:From:In-Reply-To:From; b=LH+Tz+VmJDWx9tih5nQuixQKsfRq1u06659640ce+qwswJDXQ3C6TOW8Q9ZdZ6Wg0 uycwnflBnN+rPCxvRiRyernLZX2GT4D66nNFGDeV58tmXt9Ct3gZxDhkC07eARHozp GtC7Sf6Mt8Y4w/Vc0ZHmtnbvvqdjckhzr/9DG9tk= 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 D31201E05C; Wed, 23 Apr 2025 13:22:37 -0400 (EDT) Message-ID: <6785bbf8-4a37-454a-abcb-747f27b8e153@simark.ca> Date: Wed, 23 Apr 2025 13:22:37 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 11/28] Rewrite the .gdb_index reader To: Tom Tromey , gdb-patches@sourceware.org References: <20250402-search-in-psyms-v2-0-ea91704487cb@tromey.com> <20250402-search-in-psyms-v2-11-ea91704487cb@tromey.com> Content-Language: en-US From: Simon Marchi In-Reply-To: <20250402-search-in-psyms-v2-11-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: > This patch rewrites the .gdb_index reader to create the same data > structures that are created by the cooked indexer and the .debug_names > reader. > > This is done in support of this series; but also because, from what I > can tell, the "templates.exp" change didn't really work properly with > this reader. > > In addition to fixing that problem, this patch removes a lot of code. > > Implementing this required a couple of hacks, as .gdb_index does not > contain all the information that's used by the cooked index > implementation. > > * The index-searching code likes to differentiate between the various > DWARF tags when matching, but .gdb_index lumps many things into a > single "other" category. To handle this, we introduce a phony tag > that's used so that the match method can match on multiple domains. > > * Similarly, .gdb_index doesn't distinguish between the type and > struct domains, so another phony tag is used for this. > > * Support for older versions of .gdb_index is removed entirely. > > * The reader must attempt to guess the language of various symbols. > This is somewhat finicky. "Plain" (unqualified) symbols are marked > as language_unknown and then a couple of hacks are used to handle > these -- one in expand_symtabs_matching and another when recognizing > "main". > > For what it's worth, I consider .gdb_index to be near the end of its > life. While .debug_names is not perfect -- we found a number of bugs > in the standard while implementing it -- it is better than .gdb_index > and also better documented. > > After this patch, we could conceivably remove dwarf_scanner_base. > However, I have not done this. > > Finally, this patch also changes this reader to dump the content of > the index, as the other DWARF readers do. This can be handy when > debugging gdb. I'm not knowledgeable enough with the .gdb_index quirks to have an informed opinion about this. I am happy with this change because it brings it in line with the other two we already have (.debug_info and .debug_names). I noted some random comments below. > diff --git a/gdb/dwarf2/cooked-index-shard.c b/gdb/dwarf2/cooked-index-shard.c > index 29a8aea513786e4c1c1ed77dee8610fc329d1c8a..888a0fa345b9124e2814aa722e71a9d2fd5adf8e 100644 > --- a/gdb/dwarf2/cooked-index-shard.c > +++ b/gdb/dwarf2/cooked-index-shard.c > @@ -86,7 +86,16 @@ cooked_index_shard::add (sect_offset die_offset, enum dwarf_tag tag, > implicit "main" discovery. */ > if ((flags & IS_MAIN) != 0) > m_main = result; > - else if ((flags & IS_PARENT_DEFERRED) == 0 > + /* The language check here is subtle: it exists solely to work > + around a bug in .gdb_index. That index does not record > + languages, but it might emit an entry for "main". However, > + recognizing this "main" as being the main program would be wrong > + -- for example, an Ada program has a C "main" but this is not the > + desired target of the "start" command. Requiring the language to > + be set here avoids over-eagerly setting the "main" when using > + .gdb_index. Should .gdb_index ever be removed (PR symtab/31363), > + the language_unknown check here could also be removed. */ > + else if (lang != language_unknown Did you remove the IS_PARENT_DEFERRED check on purpose? > @@ -203,10 +209,10 @@ enum class cooked_state > /* An object of this type controls the scanning of the DWARF. It > schedules the worker tasks and tracks the current state. Once > scanning is done, this object is discarded. > - > + Trailing spaces ^. > +/* This is like a cooked index, but as it has been ingested from > + .gdb_index, it can't be used to write out an index. */ > + > +class cooked_gdb_index : public cooked_index Technically, I think it should be "This is a cooked index as ingested from .gdb_index". You know, the "is-a" relationship. Currently, the base class is the "from .debug_info" case and we have some derived classes for the indexes. I feel like we should (eventually) move to having an abstract base class and add a derived class for the "from .debug_info" case. > + /* Note that this assumes the final component ends in \0. */ > + cooked_index_entry *entry = result.add (per_cu->sect_off, tag, > + flags, this_lang, > + components.back ().data (), > + nullptr, per_cu); > + /* Don't bother pushing if we do not need a panrent. */ panrent -> parent Simon