From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id uQeNNfOm6GmYjTMAWB0awg (envelope-from ) for ; Wed, 22 Apr 2026 06:46:11 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=vrany.io header.i=@vrany.io header.a=rsa-sha256 header.s=protonmail3 header.b=UazOtGtV; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id D26721E0B1; Wed, 22 Apr 2026 06:46:11 -0400 (EDT) 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 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 C3FC91E0B1 for ; Wed, 22 Apr 2026 06:46:09 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id C81905E4CF1E for ; Wed, 22 Apr 2026 10:46:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C81905E4CF1E Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=vrany.io header.i=@vrany.io header.a=rsa-sha256 header.s=protonmail3 header.b=UazOtGtV Received: from mail-4397.protonmail.ch (mail-4397.protonmail.ch [185.70.43.97]) by sourceware.org (Postfix) with ESMTPS id D814B48FE09E for ; Wed, 22 Apr 2026 10:30:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D814B48FE09E Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=vrany.io Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=vrany.io ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D814B48FE09E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=185.70.43.97 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776853818; cv=none; b=Iv4hKlKpkpUH4tQ/dVvvCJvoPKTM91tcqq2QBbT6+1zuI/MkZa/8qnHfxUtWKjFX7uNsolAzHUFPws3Te3FtPHDuxuH4ds42IdqpJnZNMOe75eqNyR77AU/BUUCWAyc7x/3vKSDT668rAMD1WTYYQTYynh3OYE+3LozCGI6Kuas= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776853818; c=relaxed/simple; bh=MS0LlIVgBiQwGMe0g+uaB/BugZusOdZ+eSCxNes6NtU=; h=DKIM-Signature:Date:To:From:Subject:Message-ID:MIME-Version; b=heuIU71BkBTAnr9KnKHjUDtieXrN6oNNnBKd00AIpETrbxyc8EOhUnSg/7B5STKjHkvF0ZDt2fa03o6vR58d0LmJG98eS5a8EVE189/xpnI0Mren9arsmu0tnrsuoRqG/xjDJMXRDVg8VRvtQQLfKGntbL76vLTH+F37Lds+Zf4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D814B48FE09E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrany.io; s=protonmail3; t=1776853816; x=1777113016; bh=D6w+SP7e82uZ3Vt99Nx3vylOpmWYa5/+9TiHRjte3JI=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=UazOtGtVsnlVdcRq7N2Q4wvw4lRIMgylUPwUvpIcAvt7OeoL5yerpvHezaKaoool0 cJzlWwhouApBHsN6678mS3FUiEOo+YOutQL2UNNnhwCKWlFUhqPi3EDrkxDqisqKbf Cr9mvsVrB6pb4tbDDFd5B0w36SdLb6UyfFc8pL1u+S8mirFwIZnwWXw6MhaCtSTHPX I++D9uM/QlBPp4hglLWXjxf0ZKXuKU+eWcjxfIZb66uaoYE0WIV6/h3/yM3pnb/ANS dVK5bku7l5C3mzxhJkdU5spYA4BStUawznOVYDiGGdrfEFtZcbRAF7Cm8+MOeVxnSa 7mGrHVIBlxwpA== Date: Wed, 22 Apr 2026 10:30:12 +0000 To: gdb-patches@sourceware.org From: Jan Vrany Cc: Jan Vrany Subject: [PATCH v3 5/7] gdb: do not set blockvector address map Message-ID: <20260422102923.1185738-6-jan@vrany.io> In-Reply-To: <20260304165914.3209106-1-jan.vrany@labware.com> References: <20260304165914.3209106-1-jan.vrany@labware.com> Feedback-ID: 40767693:user:proton X-Pm-Message-ID: 4f945ec96c23893696f12294b1ef31f64aa8a337 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 This commit removes the code that sets blockvector's addrmap in case one or more blocks are non-contiguous. Following commit will fix GDB to handle such blocks without use of the addrmap. Testing on Debian x86_64 using with and without -readnow, I see no new regressions except following: FAIL: gdb.dwarf2/debug-names.exp: print _start This is caused by discrepancy between the debug info and the debug names and will be eventually fixed in a separate patch. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=3D33829 --- gdb/buildsym.c | 55 ++------------------------------------------------ 1 file changed, 2 insertions(+), 53 deletions(-) diff --git a/gdb/buildsym.c b/gdb/buildsym.c index 9799af17f32..c343e1d10f7 100644 --- a/gdb/buildsym.c +++ b/gdb/buildsym.c @@ -316,18 +316,10 @@ buildsym_compunit::make_blockvector () std::unique_ptr blockvector; int i; =20 - /* Count the length of the list of blocks. Also, if any blocks are - non-contiguous then we need to make use of the addrmap for mapping - addresses to blocks (PENDING_ADDRMAP_INTERESTING is set to true). If - all the blocks are contiguous then we can avoid creating the addrmap, - and perform block look up using the blockvector. */ + /* Count the length of the list of blocks. */ =20 - bool pending_addrmap_interesting =3D false; for (next =3D m_pending_blocks, i =3D 0; next; next =3D next->next, i++) - { - if (!next->block->is_contiguous ()) -=09pending_addrmap_interesting =3D true; - } + ; =20 blockvector =3D std::make_unique (i); =20 @@ -345,49 +337,6 @@ buildsym_compunit::make_blockvector () m_pending_block_obstack.clear (); m_pending_blocks =3D nullptr; =20 - /* If we needed an address map for this symtab, record it in the - blockvector. */ - if (pending_addrmap_interesting) - { - struct addrmap_mutable pending_addrmap; - int num_blocks =3D blockvector->num_blocks (); - - /* If PENDING_ADDRMAP_INTERESTING is true then we must have seen -=09 an interesting block. If we see one block, then we should at a -=09 minimum have a global block, and a static block. */ - gdb_assert (num_blocks > 1); - - /* Assert our understanding of how the blocks are laid out. */ - gdb_assert (blockvector->block (0)->is_global_block ()); - gdb_assert (blockvector->block (1)->is_static_block ()); - - /* The 'J > 1' here is so that we don't place the global block into -=09 the map. For CU with gaps, the static block will reflect the -=09 gaps, while the global block will just reflect the full extent of -=09 the range. */ - for (int j =3D num_blocks; j > 1; ) -=09{ -=09 --j; -=09 struct block *b =3D blockvector->block (j); - -=09 gdb_assert (!b->is_global_block ()); - -=09 if (b->is_contiguous ()) -=09 pending_addrmap.set_empty (b->start (), (b->end () - 1), b); -=09 else -=09 { -=09 for (const auto &br : b->ranges ()) -=09=09pending_addrmap.set_empty (br.start (), (br.end () - 1), b); -=09 } -=09} - - blockvector->set_map -=09(new (&m_objfile->objfile_obstack) addrmap_fixed -=09 (&m_objfile->objfile_obstack, &pending_addrmap)); - } - else - blockvector->set_map (nullptr); - /* Some compilers output blocks in the wrong order, but we depend on their being in the right order so we can binary search. Check the order and moan about it. --=20 2.53.0