From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id gczyLlEZXGl8tC0AWB0awg (envelope-from ) for ; Mon, 05 Jan 2026 15:04:33 -0500 Authentication-Results: simark.ca; dkim=fail reason="signature verification failed" (768-bit key; unprotected) header.d=tromey.com header.i=@tromey.com header.a=rsa-sha256 header.s=default header.b=FeGFcGjz; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id BD1B21E0B6; Mon, 05 Jan 2026 15:04:33 -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.1 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_INVALID,DKIM_SIGNED,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 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 CC9A91E08D for ; Mon, 05 Jan 2026 15:04:32 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 65EF64BA2E22 for ; Mon, 5 Jan 2026 20:04:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 65EF64BA2E22 Authentication-Results: sourceware.org; dkim=fail reason="signature verification failed" (768-bit key, unprotected) header.d=tromey.com header.i=@tromey.com header.a=rsa-sha256 header.s=default header.b=FeGFcGjz Received: from omta038.useast.a.cloudfilter.net (omta038.useast.a.cloudfilter.net [44.202.169.37]) by sourceware.org (Postfix) with ESMTPS id 8E30E4BA2E1E for ; Mon, 5 Jan 2026 20:03:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8E30E4BA2E1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tromey.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 8E30E4BA2E1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=44.202.169.37 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1767643412; cv=none; b=gpaEu2dXDqlfeq/LGH24Jbclx/0YcIKgsyuanoaEirkHiZdfMBVWWe7gUdaVle5wFOMA9rKrdfkba5fhOH9VI3czsitNgppndXaxwCuBsxUDPfhMhbjBR7jd2nkZNDv8X+7tXayVdpVi8atuM7vgq8F/NykY+p4huhclphBbS0M= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1767643412; c=relaxed/simple; bh=Msr9mVevvQf2POpevTU6E3FMK/HzHKOpSxJb4oi2Mw8=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=OX2Kk7sYTyHYMm1grUQDvor7PwC2jAOu7Rc7GfkbrtYZiCTuBf2Wim7Y2zvz8k4BnN1WZ2UHw9HdIgvpic+O8BVVVV0jtZW2WrDm6r2so3gmj8QDgsP0IVnEb70BRe+IupwYAmlT/ylDJBDkBSF3vro+5kWwfk25PZKVVSioTlk= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8E30E4BA2E1E Received: from eig-obgw-6002b.ext.cloudfilter.net ([10.0.30.203]) by cmsmtp with ESMTPS id cqBoverAPSkcfcqncvNaqH; Mon, 05 Jan 2026 20:03:32 +0000 Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTPS id cqnbv35ALPL32cqnbvdPaq; Mon, 05 Jan 2026 20:03:31 +0000 X-Authority-Analysis: v=2.4 cv=MqhS63ae c=1 sm=1 tr=0 ts=695c1913 a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=vUbySO9Y5rIA:10 a=ItBw4LHWJt0A:10 a=20KFwNOVAAAA:8 a=3E1VNtBmpUb8xuwAneoA:9 a=DCx65vhANUyCzuf5D8fC:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To :Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=S464BimItLr0p2/0X8mGNgwN1JPwkwIcyOuisv98c6Y=; b=FeGFcGjzeeNjyPra4PudUnycM4 jc69fiOfTPBi16wHanPrq/MjwOFf1fA474Eea9LLDklm5M9x2wJU8tvud+E9eDj932vUPPoxjgH8j VCplTKsBwATqop/+HeeRgOfaF; Received: from 75-166-246-134.hlrn.qwest.net ([75.166.246.134]:34658 helo=bapiya) by box5379.bluehost.com with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vcqnb-00000003MjL-0Thi; Mon, 05 Jan 2026 13:03:31 -0700 From: Tom Tromey To: Andrew Burgess Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCHv3 5/7] gdb: create address map after parsing all DIE In-Reply-To: <87o6ncyns4.fsf@redhat.com> (Andrew Burgess's message of "Fri, 02 Jan 2026 16:36:43 +0000") References: <87ikg09cnl.fsf@tromey.com> <87o6ncyns4.fsf@redhat.com> X-Attribution: Tom Date: Mon, 05 Jan 2026 13:03:29 -0700 Message-ID: <878qebvnce.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 75.166.246.134 X-Source-L: No X-Exim-ID: 1vcqnb-00000003MjL-0Thi X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 75-166-246-134.hlrn.qwest.net (bapiya) [75.166.246.134]:34658 X-Source-Auth: tom+tromey.com X-Email-Count: 2 X-Org: HG=bhshared;ORG=bluehost; X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-CMAE-Envelope: MS4xfGAyWG46eksEh4EwcdncBT3O4OgYMyGSRupEBg1v5Un/udOMzCfFTMJaCusGZ+wRw4VpRvaHPPytvoUgEFCtZQ1hMEfPt0F5DIekETkxSpSLHoWKq4gQ R/MeDyCo4Yi007fIYlO3QnUZviSNaUKA+E5O0tNudhYdY6+DjlMU/ZIwA7hxxPUMnUGAOqPTT8HOL/tWzZRpHjP+xABLZkEa6VQ= 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 >>>>> "Andrew" == Andrew Burgess writes: Andrew> The addrmap requires that we add the most inner blocks first. I Andrew> achieve this by walking the blockvector backward, as we always add Andrew> parent blocks before their more inner child blocks. >> I wonder if this is guaranteed to be correct. Like, does gdb cope >> properly if a compiler happens to emit multiple lexical scopes that each >> have non-contiguous ranges, and then where the ranges happen to overlap. [...] Andrew> Now the two lexical blocks are siblings, but if we make the second block Andrew> overlap the first then this patch does cause problems. [...] Andrew> This DOES change GDB's behaviour. Andrew> Is this sibling case the type of case you were thinking of? Or have I Andrew> got the wrong end of the stick here? I think your analysis is in line with what I was thinking. My main concern is whether incorrect input can make gdb crash by violating some addrmap invariant; and then also if sufficiently weird but nominally valid input can make gdb do the wrong thing. >> I wonder why buildsym even tries to see if the pending addrmap might be >> interesting. It seems to me that a fixed addrmap is basically the same >> data structure as the blockvector: it maps addresses to blocks and uses >> a binary search to find the correct entry. Andrew> Sure, but I wonder if this is a memory use thing? The addrmap must use Andrew> more memory than the vector, so maybe for large programs this would be a Andrew> noticable hit. Yeah, I think what I meant is gdb could perhaps just dispense with the vector entirely and only store the addrmap. Though I don't actually want that outcome because I would like the blockvector to be expandable. This isn't readily possible with addrmap due to the bottom-up requirement. Andrew> There are a few places where we use the block's ranges for useful work, Andrew> these would all need to be rewritten to get the same information from Andrew> the blockvector (really the addrmap within the blockvector). Ok, thanks. When this comes back around I will dig for those. >> FWIW I've been looking into this area a bit while experimenting with >> lazy CU expansion. There I think I want to make it so blockvectors are >> always expandable, so no fixed addrmap at least -- and mutable addrmaps >> have some issues with updating, so probably moving to just having a >> vector. Andrew> Wouldn't that cause problems for non-contiguous blocks? Isn't that the Andrew> problem that the addrmap was added to solve? For me the desirable end point is that blockvector is an opaque data structure, where the primary read operation is "give the block for a given PC", and queries about the internal structure of the blockvector are forbidden. Right now there is code that looks to see if there a map exists, which is an abstraction violation; and also buildsym seems to be pretty chummy with blockvector, though that's less of a problem. Now, the other thread -- the JIT stuff Jan Vrany is working on -- shows that there are still some problems to iron out here, because for reasons I don't really understand, some blockvector users seem to want to get back the static block in response to a PC lookup. (There was that issue with some code in libc that is not in a function body. But I don't understand why that's not just a bug in libc.) Other than that, though, I don't think that non-contiguous blocks present a problem. Their existence would be hidden by the blockvector API. Though I may not appreciate this fully either. Anyway my current idea for lazy expansion is to record incomplete symbols for functions, so that if a blockvector lookup finds a block corresponding to such a function, it would first be expanded to find the correct enclosed block. Tom