From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 3MLRDBERgmmwGyYAWB0awg (envelope-from ) for ; Tue, 03 Feb 2026 10:15:29 -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=UTA/8g2W; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 1D6931E0BA; Tue, 03 Feb 2026 10:15:29 -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 DFF6A1E08D for ; Tue, 03 Feb 2026 10:15:27 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 4FE644BA23C9 for ; Tue, 3 Feb 2026 15:15:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4FE644BA23C9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1770131727; bh=CxtZMP4WebHoDkk4YwWC2pne5h+lDRyMGCIMvpwKU1I=; h=Date:To:Cc:Subject:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=UTA/8g2WZ2v3lAavmfAAmIUFlzOSa+IYssGZOtCgOoBi1eF2JAsNmNOTTkRS59KLX t9pQICx/fWllz0NSQam++cz7UuxiIwx2hiMlZX9pMN+ASrFlHa/rQN4IgfeVrDBeue ZAeFPb0Xdd0++CnWReAErKkEVhaOTAQSoSJv6ydQ= Received: from mail-24422.protonmail.ch (mail-24422.protonmail.ch [109.224.244.22]) by sourceware.org (Postfix) with ESMTPS id 7183E4BA2E08 for ; Tue, 3 Feb 2026 15:14:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7183E4BA2E08 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7183E4BA2E08 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1770131692; cv=none; b=YdRL0ey1UgqVmHfbCm7tLxB4/A9OE2UShdX93wCL1BInmq5hIMH5t/5P1zYb5z5xLY1z0Zq3bg3YHPE2hiMEOTBp1abmW8hs/nQJ0/Sy8XI0D1zKOi7rJStkYO2S/diKGGmYek79MOH6oPAdhbhaGHZjOrJK95emG8FQGzY0FCU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1770131692; c=relaxed/simple; bh=CxtZMP4WebHoDkk4YwWC2pne5h+lDRyMGCIMvpwKU1I=; h=DKIM-Signature:Date:To:From:Subject:Message-ID:MIME-Version; b=hNWaEGk65JuA06gMCEuXMvzQp+i0FOp+076kUiISH4jIyzwq+3lsSd+B5Xgb6tK2NlEPSh2Pk5R0yqyJmuvHdeufo8U8fcTjTzvh4JcyBXxdTjoT5I0M5hHv/o92fWgwog6PiNy/Qpoqv1HpxTMR+NXfUvwYwm4iZJMQ+t5ow3A= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7183E4BA2E08 Date: Tue, 03 Feb 2026 15:14:43 +0000 To: Tom Tromey Cc: GDB Development Subject: Re: [RFC PATCH 7/8] gdb/ctf: don't use psymtabs, create symtabs directly Message-ID: <1a5011136cd40f89c01b361e18aa8d06b2f60337.camel@vrany.io> In-Reply-To: <87o6m57v46.fsf@tromey.com> References: <2e8e28fbfa4894f3f28fe86f698406c4e880753f.camel@vrany.io> <87o6m57v46.fsf@tromey.com> Feedback-ID: 40767693:user:proton X-Pm-Message-ID: d0b850d14ede89c4ffb3b1a6e74e107cd0b68bae MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Jan Vrany via Gdb Reply-To: Jan Vrany Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" On Tue, 2026-02-03 at 07:35 -0700, Tom Tromey wrote: > > > > > > "Jan" =3D=3D Jan Vrany writes: >=20 > > > In order to access the symtabs, elfctf_build_symtabs installs the > > > expanded_symbols_functions quick_symbol_functions implementation, whi= ch > > > essentially searches in the existing symtabs.=C2=A0 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.=C2=A0 But it'= s good > > > enough for a prototype. >=20 > Jan> True, but does that matter? Should that matter? >=20 > If it's possible then it could matter. >=20 > Consider if you have both a CTF and a DWARF "readnow" implementation > attached to an objfile.=C2=A0 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.=20 >=20 > In some earlier thread I proposed fixing this by adding a marker to the > compunit_symtab to record where it came from.=C2=A0 Then the "expanded > symbols for JIT" expanded-symbols instance could limit its search. >=20 > However: >=20 > Jan> Also it seems to me that this version does not allow for both CTF an= d > Jan> DWARF in single objfile: >=20 > ... do we have any spot any more that records symbols from multiple > readers?=C2=A0 Since another option would be to get rid of that ability; > unless we think it'll be used again. In "Python JIT API" series, I allow to add symbols any objfile, even the one with existing DWARF. To make this work, I push expanded_symbols_fun= ctions to the end of qf list. Whether this is a good or bad idea, I do not know - = the reason=C2=A0 for this was to support an arguably extreme usecase where dynamic code is g= enerated=C2=A0 into statically allocated buffer or section. I'm happy to reintroduce these= checks (and therefore not supporting this usecase) if it feels "safer". Jan >=20 > Tom