From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 3stwHkMrgml9PCYAWB0awg (envelope-from ) for ; Tue, 03 Feb 2026 12:07:15 -0500 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=krKfNbMZ; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 6C38A1E08D; Tue, 03 Feb 2026 12:07:15 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.6 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,RDNS_NONE autolearn=no autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (unknown [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 C520D1E08D for ; Tue, 03 Feb 2026 12:07:14 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 556E34BA543C for ; Tue, 3 Feb 2026 17:07:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 556E34BA543C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1770138434; bh=35RXO5kANdlOyoxz/PkqjcvoYDu4uvPJFQ3eOtTpmW8=; h=Date:Subject:To:Cc:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=krKfNbMZPgrtHfVrOvuWW38omznfbfULj7vU8enaHUKZANjpdco65t9+9iuyt053O /IbESjVFKaDtKpXiFmrQhFYGqJM+hvFkB0ubgwrTLh1upxql4IkrRLEsxRE8gsgV09 jI+NZOKZ5fay9aeVsNYgXJQnDZbkf+l8YKZmK/tc= Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id C42014BA2E08 for ; Tue, 3 Feb 2026 17:06:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C42014BA2E08 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C42014BA2E08 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1770138399; cv=none; b=tCF9QgLJQKY/BbdPP79Z/QH7PvvihH3GDxIdr31GFYVvBH7Xev7rS4dRo9rhc6ijQ5S08y724jbWx/FfRa4wpG7YsgzP6FMyPwIkDOy7osaIiBBVXiVUdlgjdLaiteixkK/5yt0C8uK1wNyfs++8mOmNJ3cA6wvkwS5uhCGYRFI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1770138399; c=relaxed/simple; bh=zG2Vuhh5TKiyR64s+/CqusY1/BDhOTkl76u3CxvtTDU=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=OKmZ6sPz2U4hSUeHVEkvjKUe/T4gHJU+c50f0zfjcKXYS3Hfbu0xrWgbAD7jzkWALEa+o/CaOQmrLLKhBN3DOQ7IRu1ecKJBJpwgehOPY/qghsAfEIglmu8uSfWK0dcOpmhcDAazaLfjpiGYrMBgWs1hH65dcgNytl/CBPsLAbk= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C42014BA2E08 Received: by simark.ca (Postfix) id 027B01E08D; Tue, 03 Feb 2026 12:06:38 -0500 (EST) Message-ID: <98a883ca-d3c3-4cbe-822d-0dd7bfa9dd12@simark.ca> Date: Tue, 3 Feb 2026 12:06:38 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 7/8] gdb/ctf: don't use psymtabs, create symtabs directly To: Jan Vrany , Tom Tromey Cc: GDB Development References: <2e8e28fbfa4894f3f28fe86f698406c4e880753f.camel@vrany.io> <87o6m57v46.fsf@tromey.com> <1a5011136cd40f89c01b361e18aa8d06b2f60337.camel@vrany.io> Content-Language: fr In-Reply-To: <1a5011136cd40f89c01b361e18aa8d06b2f60337.camel@vrany.io> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Marchi via Gdb Reply-To: Simon Marchi Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" On 2/3/26 10:14 AM, Jan Vrany via Gdb wrote: > On Tue, 2026-02-03 at 07:35 -0700, Tom Tromey wrote: >>>>>>> "Jan" == Jan Vrany writes: >> >>>> In order to access the symtabs, elfctf_build_symtabs installs the >>>> expanded_symbols_functions quick_symbol_functions implementation, which >>>> essentially searches in the existing symtabs. I am pretty sure this is >>>> not 100% correct, because this would search unrelated symtabs, if for >>>> instance the CTF debug info co-existed with DWARF info. But it's good >>>> enough for a prototype. >> >> Jan> True, but does that matter? Should that matter? >> >> If it's possible then it could matter. >> >> Consider if you have both a CTF and a DWARF "readnow" implementation >> attached to an objfile. Now all searches are done twice -- probably >> won't be incorrect but it will be slower. > > In case the search fails, yes. Otherwise the first implementation that > finds something wins, the others are not tried. It looks to me this can > be easily solved by adding each implementation only once. > > As a side note, when debugging quick symbols I noticed that very often > the same thing is searched for in quick succession. There is this "set always-read-ctf" setting, which makes it possible to have both DWARF and CTF. The order of "quick functions" matters, it will affect which debug info provider will be searched first. At least this is what this commit message taught me: https://gitlab.com/gnutools/binutils-gdb/-/commit/0d5adb56c85da38a0f95e872fda05cc6446010c3 I don't really like that we rely on the order in which things are read (and therefore the order in which quick_symbol_functions objects are pushed, I suppose) to define the priority. It seems like it would be clearer if all quick_symbol_functions implementations were assigned an arbitrary "weight" to define the priority. But that's unrelated to this issue. The thing is that if expanded_symbols_functions searches all symtabs, I think it would break that priority assumption. Right now, the order of quick_symbol_functions instances defines the priority of search. With expanded_symbols_functions searching all compunit_symtabs, then the order of compunit_symtabs may affect that priority. To illustrate, a thought experiment: imagine you use both DWARF (using its cooked index) and JIT (using expanded_symbols_functions), and we define that JIT has precedence over DWARF. The user does an action that causes expansion of a DWARF symtab containing a symbol Foo. That compunit_symtab is first in the compunit_symtab list. The JIT then creates a compunit_symtab that contains another symbol Foo. Because JIT has priority, a lookup for Foo should find JIT's Foo. However, JIT's expanded_symbols_functions search will hit DWARF's compunit_symtab and find DWARF's Foo symbol. I think it would be safer for each quick_symbol_functions to search its own stuff only. What I'm thinking is that the expanded_symbols_functions can hold a vector, containing the compunit_symtabs created by this reader. The search method of expanded_symbols_functions would search those compunits. If you have both the JIT reader and the CTF reader active, then they would both push there own expanded_symbols_functions instance, with their own list of compunit_symtabs. >> In some earlier thread I proposed fixing this by adding a marker to the >> compunit_symtab to record where it came from. Then the "expanded >> symbols for JIT" expanded-symbols instance could limit its search. This would be functionally similar to what I proposed above, I think. Simon