From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id SrNnOh8UN2nFuiQAWB0awg (envelope-from ) for ; Mon, 08 Dec 2025 13:08:31 -0500 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=labware.com header.i=@labware.com header.a=rsa-sha256 header.s=mimecast20220511 header.b=MyFkvNl8; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id D4DCD1E08D; Mon, 08 Dec 2025 13:08:31 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: *** X-Spam-Status: No, score=3.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_SBL_CSS,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED, URIBL_CSS_A autolearn=no 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 6007D1E08D for ; Mon, 08 Dec 2025 13:08:30 -0500 (EST) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B3C3E473D187 for ; Mon, 8 Dec 2025 18:08:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B3C3E473D187 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=labware.com header.i=@labware.com header.a=rsa-sha256 header.s=mimecast20220511 header.b=MyFkvNl8 Received: from us-smtp-delivery-114.mimecast.com (us-smtp-delivery-114.mimecast.com [170.10.133.114]) by sourceware.org (Postfix) with ESMTP id 7F8D74CF31CD for ; Mon, 8 Dec 2025 18:08:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7F8D74CF31CD Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=labware.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=labware.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7F8D74CF31CD Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.114 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1765217282; cv=none; b=oAMY3qmJpMOUFID7lwguEwrhYLLjga5zutzv4muMQE15XwnpA51XL6jZZmfJ1iQiLWtF53qIPXSQE329ERbVKVZOwTuimKX7lhQboQeJ5ONwPgG7Evrukk7IMZyk6STIoUvwvlFzcBsQkXT2w0AC/BlH+WNkTT6cOpLS5KocdLA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1765217282; c=relaxed/simple; bh=NcK9Aez2rBCX29ZsJsV9CV/WojcebUaqYrvi/32JqWE=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=OwCBnC5X+YIOTQNkPFZmV29juXAPN5Ejp+6eA2Lj1b7YPbBv+Ow6YuRr612aQDlG6qwfGhP/Ee/5uqREAgAeCE+5L4A9BLOHSU9rzq49iS0JZ460qrWnrq6fE0JlG+cSQzai2XbDwfaLR6JSEv4DGvxRZZ9/kR4bMYR8tJYatfU= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7F8D74CF31CD DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=labware.com; s=mimecast20220511; t=1765217282; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=fyA2CPBUMYxESlgdxKGL4q4hFXfc85R4NSdslkXBE64=; b=MyFkvNl8KCMSHk/ZakD8ryadHr3kYpUhy78x1Ln6t5Mq4dwtbPEuUDpOcP93/V7WVbJrDm g8wlX8oWuL7Qhgkg8ziEn0kVqJH7OSO1KfmzsOrb7oJbP6Irsgsz5o8BjH8KaKqsH6eGM7 ORiKualPMt5asXTWHiYGzmr75dJTuoM= Received: from PH8PR06CU001.outbound.protection.outlook.com (mail-westus3azon11022079.outbound.protection.outlook.com [40.107.209.79]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-98-LofdP1tTM-OX8cwGRllZiA-1; Mon, 08 Dec 2025 13:07:59 -0500 X-MC-Unique: LofdP1tTM-OX8cwGRllZiA-1 X-Mimecast-MFC-AGG-ID: LofdP1tTM-OX8cwGRllZiA_1765217277 Received: from SA1PR17MB5365.namprd17.prod.outlook.com (2603:10b6:806:1d8::11) by MN2PR17MB3885.namprd17.prod.outlook.com (2603:10b6:208:205::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9412.6; Mon, 8 Dec 2025 18:07:55 +0000 Received: from SA1PR17MB5365.namprd17.prod.outlook.com ([fe80::9a:538a:fa42:730e]) by SA1PR17MB5365.namprd17.prod.outlook.com ([fe80::9a:538a:fa42:730e%3]) with mapi id 15.20.9412.005; Mon, 8 Dec 2025 18:07:55 +0000 From: Jan Vrany To: gdb-patches@sourceware.org CC: Jan Vrany , vries@gcc.gnu.org, tromey@sourceware.org, thiago.bauermann@linaro.org, simon.marchi@efficios.com Subject: [PATCH] Revert "gdb: change blockvector::contains() to handle blockvectors with "holes"" Date: Mon, 8 Dec 2025 18:07:17 +0000 Message-ID: <20251208180717.176567-1-jan.vrany@labware.com> X-Mailer: git-send-email 2.51.0 X-ClientProxiedBy: LO2P123CA0058.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1::22) To SA1PR17MB5365.namprd17.prod.outlook.com (2603:10b6:806:1d8::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SA1PR17MB5365:EE_|MN2PR17MB3885:EE_ X-MS-Office365-Filtering-Correlation-Id: 6278c588-358f-48e6-cab0-08de3684b5fc X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014 X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?3FYN4enaIc3pkuoJYlFF+7ubV1QCstWYHIm+0/Gs/WTrCGgAthR/K3WATwIY?= =?us-ascii?Q?iLDriqIDN5pDY0C9dqtgwqBIsgVKX0GCmXeGV4zduocHww2dfoyqybvpSPk9?= =?us-ascii?Q?HGEcVBuNTt543LNUuU+cMUwG/fuFYFEgVa4cGZ0NpokJcBBrv7Y581+MKDkO?= =?us-ascii?Q?43YkVw3TJ5P89kcGgX2P0nB3cwsaKCks3P9rhhf/S7jaB0Tvt32EU869giEJ?= =?us-ascii?Q?6M38xzUTJptDllK3h+WaJT5a9nZNHTQ7XZ3Ypwckeubco17AIfopi91Wn7SJ?= =?us-ascii?Q?rsKp/ndBS7mb4u5gWrlmCW6T4ANaTH9RdtU3ckmPc2zBnoIhxfk7JTPe/v1e?= =?us-ascii?Q?+WW5LZuHLA+Qb2Nil7o+Edz5opkiKM7AHsrWtSKGNCgQgzB5dMpWX357jGh5?= =?us-ascii?Q?wVMhtq1+xe+6uM52qr1SKGAKDN8gX4LFyDCwlLCmudJnQBWVKHF4wTWlPSFV?= =?us-ascii?Q?kh6oL2TIUL1PZULPCyosxyGjXD53J+lu2/lRqhjnEm66muExuDUgU+PXOCta?= =?us-ascii?Q?VhVWvukG5VlcJ0aumAo4fSHPyzB76yvyX7pSGHShyI+bP86Z09Dvw99L2C3k?= =?us-ascii?Q?CpJ2mZw0PYTfzb7V6qbJMdvG3ObmM31zEis58YYsagVhrXcR0hxq7DoYSmW3?= =?us-ascii?Q?zFDGEVRqxmO7QKgJv7x0kXmmDv0IntFNHnEfIqow2htM4t+14/oIgDC7S3/c?= =?us-ascii?Q?GIKTK2tE7Rg3S6V99DhORF2+S3WqIK4ugW6uprOQUgfnNVz857bYUjo29jIj?= =?us-ascii?Q?VJKbIryh5l1utr6ZkTH3rCbt/4tzxDO6+JkR2xvHlRlh2SgTQ8punXFUwai4?= =?us-ascii?Q?a49ax+mf3OLRcbfKiaB7Xw8Xkifv8KKunNlhV/0Fxk8wMFKX1YQZrxQfxADj?= =?us-ascii?Q?aouy4nkFjwLHGN/lY1rgCWx766OffaTJKvRTpg3+jbBABh5H9t470168RdCP?= =?us-ascii?Q?0Lvrr1lPD7HclQ1u2s0v9GzYCCEaEy4anELVX5Ub/2/gPX6weZ95267YbRjP?= =?us-ascii?Q?8eY2mCJMh266vfe6rbtFzKSOMQTq5ztkk/9SkiyYfIq4t01qL8sEqujijSfn?= =?us-ascii?Q?Unt7QfJ5sn8Vkt0aC2xyLQTK/hQ7fkZKNETFDXWRB3ReiukPUb9k1T+jdgav?= =?us-ascii?Q?09XnGEOKqXFxcwX0b9wfmd+2KCN1wr5t5DM3f5fgZYpa0eVzdq5O/OZEhqEy?= =?us-ascii?Q?HSrm4GTqFZNgk6YH/Rlt4n9z0hrvFSjmSaFhgqpproesmlGAj1/Jy8XVh40n?= =?us-ascii?Q?fUIhJyQ31vDAYX0P65EP+xlEs+BjIdz+adGqbJeahvRuqk4HaRDt+WITq3hX?= =?us-ascii?Q?cSWDcIgdEQG2/8sUjGcSat36xjtL4ak5SKWI1giwh3dn/x+6YB8NqDpZg7XJ?= =?us-ascii?Q?RDq4K68mFQHRnNcM1JydCgWu3BFlJFs28S5i6VSOzFUj9DmZ5w=3D=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA1PR17MB5365.namprd17.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(366016)(1800799024)(376014); DIR:OUT; SFP:1102 X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?aPceUg5mrCbKU0IHWFEWEK+yWBJYy5Vsvqaj3XpGX8AryE8gQxT/lv8zGp+1?= =?us-ascii?Q?ta7vW0w+Cb3ZgA/o69ZCmAPOAtDaje+cSCPXedzemzH02LN6KT7wXQC4vITM?= =?us-ascii?Q?Fof5Hc/W0QLpsJOkl2D5i2sZMLka57LGpX3y8U9InLlTsc0raRzUraYt/l4z?= =?us-ascii?Q?z+DjgaZ04uHaWCkzVwmbaGmnfqCZ+0eOW1dyjyhdJ7InEdJ6inpQaYOKXW0w?= =?us-ascii?Q?5icPAu/ULqnbLr+JK6sVPujyoiPvOVZpGHFJOOe/DQXN2MYB3AR3L8kUpHHu?= =?us-ascii?Q?LHnmQ+mUNLhGzIWm8Qu5oQ5j3oy75ZLHAbnpNZcGdghMnMgUl/CfHbBUOFi9?= =?us-ascii?Q?QBZ2IfvtTAfg2Wv7o82rwW/uDUoeA88wXxwyDM17+UHuwa1TKkTvGm5Vb0Wl?= =?us-ascii?Q?OJPH53DAaH9OhsYJ2GyhGmycdS3/NF3e0rQlNwKfTJ60h/TSXBMP6PICtuW0?= =?us-ascii?Q?kM0Q0Mkjsh+cJCIeB7vslOM8Vd7elK0weZp3DMAnxo/yhKwGH27bWkZuR4OE?= =?us-ascii?Q?Wp1ynUXPhxMjt2twb6UU80ZQqKAxy7QTIggES+2Wb3mUL26SXFuXFDwCC/RC?= =?us-ascii?Q?n2yUeQEh4FIBnOS1yzcp69gYOwovOu2bPlXRGVk3dZ73iw2gKhNIevSPkgHY?= =?us-ascii?Q?vsB8Gp7+1wFfjoWwzd1gJL3o1ocPn9cAY7anDvA927gSG8EXSWU++VxnYPK/?= =?us-ascii?Q?y8JZII53BxT7FSiWS1mhKt4Drv/nBZzIsJSKgq014Fxd8z1oYwxyHIBfJzBN?= =?us-ascii?Q?ilpTtKvvFvF1E3ipiv8W59enelFbq0sl4c8mT6HSK6kp960/i5YaV77RbYQM?= =?us-ascii?Q?mKicMb4i1/B0XE4D2Lc7N8VMZP1S2qG0OEWFWVa/WQImfDozk8L2V625N9rl?= =?us-ascii?Q?2c+IubR6+fwobAXIP+ZXTltBDyA4NYeCtb9cIQEPH3uZIKBnz6awUl8e2l4M?= =?us-ascii?Q?cK/tPV/yyW2wCjaR8/kTwdNDIdxo5p/ZPJut9ADuTy7WvIIMSSndnz1lcXU0?= =?us-ascii?Q?tlATDN0W2MyJ3AZLstOQk47IyZJP8m5XN8S0vt/MCqGNNrIh1EkOoVSu/r4d?= =?us-ascii?Q?g5ayV9HD6r2od2l5S5u9GBRo6rgBpTiIRjXVPbzPmMRBwTZofxStUKgpK0n3?= =?us-ascii?Q?aHX0UOF/q/S0iTJKiFQhSwQ+q26vYbdF+Sh4HXoGsvcc5PeJUOTxSEuqZOG3?= =?us-ascii?Q?+YSc8/qwHhWZsxQpMEagKCDO7/21a0DDZ6++GOWIpInk9BYMWJjbCBnWlm1R?= =?us-ascii?Q?w3zNVD6CSWGiiR988tiKDTtKLThGK9lkZ8n4kFecLCdccGpcnsxN/Sc2M8KW?= =?us-ascii?Q?imNp27fIf8kLfsb6bT98rlxRDL4YHScT7Ft4A/cdjwVKp7qRAUfuh/JAM40b?= =?us-ascii?Q?+Ip3TdnfM1MtywhU66463Zy6toV3yyp1NblcEEI7kcxdr/Qhgi8i/zZTi9Vj?= =?us-ascii?Q?rBpFadZ854aAQXSMddNQA4kj93TGfYrhVYZDuNeXkY+mnaLA9p7x9I0J5FQG?= =?us-ascii?Q?UWLMXtB3P1yVAocGvF077nozmE10FF/HVaSytf4Y2UCTYac5bm1tVQUvdM0P?= =?us-ascii?Q?x1iRSTlz1CUSixuBQTn2tJeBNvYsfDXQrQ5sRhmC?= X-OriginatorOrg: labware.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6278c588-358f-48e6-cab0-08de3684b5fc X-MS-Exchange-CrossTenant-AuthSource: SA1PR17MB5365.namprd17.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Dec 2025 18:07:55.3385 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b5db0322-1aa0-4c0a-859c-ad0f96966f4c X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: c+7TYSYR9jHYtMQZizv+CVhCuiAV2RLOOGIS5N84MnafWrO2rSwX//B6j1MBaD+c+VNOlqdDlQpk/tACPbvgJw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR17MB3885 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: jUi-WFAOxn8w0lft_F5Eh7mfTbPDe0sK1X07sr-wD9c_1765217277 X-Mimecast-Originator: labware.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252 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 reverts commit cc1fc6af4150b19f9c4c70d0463ff498703fb637, since it causes a number of regressions that seem not to be easily fixable. The problem lies in existence of "freestanding" code, a code that is part of a CU but does not have any block associated with it. Consider following program: __asm__( ".type foo,@function \n" "foo: \n" " mov %rdi, %rax \n" " ret \n" ); static int foo(int i); int main(int argc, char **argv) { return foo(argc); } When compiled, the foo function has no block of itself: Blockvector: no map block #000, object at 0x55978957b510, 1 symbols in 0x1129..0x1148 int main(int, char **); block object 0x55978957b380, 0x112d..0x1148 se= ction .text block #001, object at 0x55978957b470 under 0x55978957b510, 2 symbols = in 0x1129..0x1148 typedef int int; typedef char char; block #002, object at 0x55978957b380 under 0x55978957b470, 2 symbol= s in 0x112d..0x1148, function main int argc; computed at runtime char **argv; computed at runtime In this case lookup(0x1129) returns static block and, because of the change in cc1fc6af4, contains(0x1129) which is wrong. Such "freestanding" code is perhaps not common but it does exist, especially in system code. In fact the regressions were at least in part caused by such "freestanding" code in glibc (libc_sigaction.c). The whole idea of commit cc1fc6af4 was to handle "holes" in CUs, a case where one CU spans over multiple disjoint regions, possibly interleaved with other CUs. Consider somewhat extreme case with two CUs: /* hole-1.c */ int give_me_zero (); int main () { return give_me_zero (); } /* hole-2.c */ int __attribute__ ((section (".text_give_me_one"))) __attribute__((= noinline)) baz () { return 42; } __asm__( ".section .text_give_me_one,\"ax\",@progbits\n" ".type foo,@function \n" "foo: \n" " mov %rdi, %rax \n" " ret \n" " nop \n" " nop \n" " nop \n" ); int __attribute__ ((section (".text_give_me_one"))) __attribute__((noin= line)) give_me_one () { return 1; } __asm__( ".section .text_give_me_zero,\"ax\",@progbits\n" "bar: \n" " jmp give_me_one \n" " nop \n" " nop \n" " nop \n" ); int __attribute__ ((section (".text_give_me_zero"))) give_me_zero () { extern int bar(); return give_me_one() - 1; } This when compiled with a carefully crafted linker script to force code at certain positions, creates following layout: 0x080000..0x080007 # "freestanding" bar from hole-2.c 0x080008..0x080016 # give_me_zero() from hole-2.c 0x080109..0x080114 # main from hole-1.c 0xf00000..0xf0000b # baz() from hole-2.c 0xf0000b..0xf00011 # "freestanding" foo from hole-2. 0xf0000b..0xf0001c # gice_me_one() from hole-2. The block vector for hole-1.c looks: Blockvector: no map block #000, object at 0x555a5d85fb90, 1 symbols in 0x80109..0x80114 int main(void); block object 0x555a5d85faa0, 0x80109..0x80114 section = .text block #001, object at 0x555a5d85faf0 under 0x555a5d85fb90, 1 symbols = in 0x80109..0x80114 typedef int int; block #002, object at 0x555a5d85faa0 under 0x555a5d85faf0, 0 symbol= s in 0x80109..0x80114, function main And for hole-2.c: Blockvector: map 0x0 -> 0x0 0x80008 -> 0x555a5d85ff50 0x80016 -> 0x0 0xf00000 -> 0x555a5d860280 0xf0000b -> 0x0 0xf00012 -> 0x555a5d860110 0xf0001d -> 0x0 block #000, object at 0x555a5d8603b0, 3 symbols in 0x80008..0xf0001d int give_me_zero(void); block object 0x555a5d85ff50, 0x80008..0x80016 = section .text int give_me_one(void); block object 0x555a5d860110, 0xf00012..0xf0001d= section .text int baz(void); block object 0x555a5d860280, 0xf00000..0xf0000b section= .text block #001, object at 0x555a5d8602d0 under 0x555a5d8603b0, 1 symbols = in 0x80008..0xf0001d typedef int int; block #002, object at 0x555a5d85ff50 under 0x555a5d8602d0, 0 symbol= s in 0x80008..0x80016, function give_me_zero block #003, object at 0x555a5d860280 under 0x555a5d8602d0, 0 symbol= s in 0xf00000..0xf0000b, function baz block #004, object at 0x555a5d860110 under 0x555a5d8602d0, 0 symbol= s in 0xf00012..0xf0001d, function give_me_one Note that despite the fact "freestanding" bar belongs to hole-2.c, the corresponding CU's global and static blocks start at 0x80008! Looking at DWARF for the second program, it looks like that the compiler (GCC 15) did not record the presence of "freestanding" code: <0><71>: Abbrev Number: 1 (DW_TAG_compile_unit) <72> DW_AT_producer : (indirect string, offset: 0): GNU C23 15= .2.0 -mtune=3Dgeneric -march=3Dx86-64 -g -fasynchronous-unwind-tables <76> DW_AT_language : 29 (C11) <77> Unknown AT value: 90: 3 <78> Unknown AT value: 91: 0x31647 <7c> DW_AT_name : (indirect line string, offset: 0x2d): ho= le-2.c <80> DW_AT_comp_dir : (indirect line string, offset: 0): test_= programs <84> DW_AT_ranges : 0xc <88> DW_AT_low_pc : 0 <90> DW_AT_stmt_list : 0x51 and corresponding part of .debug_aranges: Length: 76 Version: 2 Offset into .debug_info: 0x65 Pointer Size: 8 Segment Size: 0 Address Length 0000000000f00000 000000000000000b 0000000000f00012 000000000000000b 0000000000080008 000000000000000e 0000000000000000 0000000000000000 Thiago suggested to use minsymbols to tell whether or a CU contains given address. I do not think this would work reliably as minsymbols do no know to which CU they belong. In slightly more complicated case of interleaved CUs it does not seem to be possible to tell for sure to which one a given minsymbol belongs. Moreover, Tom suggested that the comment in find_compunit_symtab_for_pc_sec= t (which led to cc1fc6af4) may be outdated [2]. Given all that, I'm just reverting the change. [1]: https://sourceware.org/bugzilla/show_bug.cgi?id=3D33679#c13 [2]: https://inbox.sourceware.org/gdb-patches/87cy6xzd3j.fsf@tromey.com/ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=3D33679 --- gdb/block.c | 29 +---------------------------- 1 file changed, 1 insertion(+), 28 deletions(-) diff --git a/gdb/block.c b/gdb/block.c index 3d2c51cc554..e21580bcf63 100644 --- a/gdb/block.c +++ b/gdb/block.c @@ -864,34 +864,7 @@ blockvector::lookup (CORE_ADDR addr) const bool blockvector::contains (CORE_ADDR addr) const { - auto b =3D lookup (addr); - if (b =3D=3D nullptr) - return false; - - /* Handle the case that the blockvector has no address map but still has - "holes". For example, consider the following blockvector: - -=09B0 0x1000 - 0x4000 (global block) -=09B1 0x1000 - 0x4000 (static block) -=09 B3 0x1000 - 0x2000 -=09=09=09=09(hole) -=09 B4 0x3000 - 0x4000 - - In this case, the above blockvector does not contain address 0x2500 b= ut - lookup (0x2500) would return the blockvector's static block. - - So here we check if the returned block is a static block and if yes, = still - return false. However, if the blockvector contains no blocks other t= han - the global and static blocks and ADDR falls into the static block, - conservatively return true. - - See comment in find_compunit_symtab_for_pc_sect, symtab.c. - - Also, note that if the blockvector in the above example would contain - an address map, then lookup (0x2500) would return NULL instead of - the static block. - */ - return b !=3D static_block () || num_blocks () =3D=3D 2; + return lookup (addr) !=3D nullptr; } =20 /* See block.h. */ --=20 2.51.0