From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id S7N7Fkr6P2k8wAEAWB0awg (envelope-from ) for ; Mon, 15 Dec 2025 07:08:42 -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=GrpWng0Q; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 4F19C1E048; Mon, 15 Dec 2025 07:08:42 -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.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 034141E048 for ; Mon, 15 Dec 2025 07:08:40 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 6E8B44BA23D2 for ; Mon, 15 Dec 2025 12:08:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6E8B44BA23D2 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=GrpWng0Q 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 0FEF44BA2E20 for ; Mon, 15 Dec 2025 12:08:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0FEF44BA2E20 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 0FEF44BA2E20 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=1765800491; cv=none; b=NjjvkbBkP+Oqb2CU+425HY8sf/h8T9Uj1h5UZvVYAokAuf6VzAPcI2SYbCgMfcjs7f0dkyECKr1RNDbb6hNE/i4uqXuMMNzjxGYA0GBc0AQ1vv34vRnSshv//uQhQYSQadE3EGRWtqAwz99Jfvc04E0N/sWXHyFrRwz3otYKN0c= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1765800491; c=relaxed/simple; bh=mqviIgeDHtKswGXo/iV5ZVifBGgtfrdzi0C0oJwDHAA=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=Kbtyml6vKeiv2GvU7sal6ssv5aprxlPaEiLBavljzQUCUFwwLund8ngb+XqvWNv4SokKjqX/vT5u4aVeD+BPzR2lurlzArsfKTwgN7GCwH2yHFR+Zul7R4CvXiBV83JGfXDjQ5x3RelZOIko8/Yxy43yF+f/ZvzRRU9M6cnwmE8= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0FEF44BA2E20 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=labware.com; s=mimecast20220511; t=1765800490; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mqviIgeDHtKswGXo/iV5ZVifBGgtfrdzi0C0oJwDHAA=; b=GrpWng0QP9eDNmkNq2627j4R8/3hxLLwYYyCGwLxnXDNeIgbsZlUmXOzGPURDU/mpyJqeS ck/uPnBBM3CHFjWTblRzTfArdtJfJtaTjm4I6eP+wJOqUrHIAPitUSNpthHVryOndUcQ7C su65o8YbzDAEXySQcm7Yksjr41GI9q4= Received: from CH5PR02CU005.outbound.protection.outlook.com (mail-northcentralusazon11022091.outbound.protection.outlook.com [40.107.200.91]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-180-XJtUOBUANFWpFaB6NbCk-Q-1; Mon, 15 Dec 2025 07:08:09 -0500 X-MC-Unique: XJtUOBUANFWpFaB6NbCk-Q-1 X-Mimecast-MFC-AGG-ID: XJtUOBUANFWpFaB6NbCk-Q_1765800488 Received: from SA1PR17MB5365.namprd17.prod.outlook.com (2603:10b6:806:1d8::11) by CH4PR17MB7403.namprd17.prod.outlook.com (2603:10b6:610:232::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9434.6; Mon, 15 Dec 2025 12:08:06 +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.9434.001; Mon, 15 Dec 2025 12:08:06 +0000 From: =?iso-8859-1?Q?Jan_Vran=FD?= To: "gdb-patches@sourceware.org" Subject: [PING] Re: [PATCH] Revert "gdb: change blockvector::contains() to handle blockvectors with "holes"" Thread-Topic: [PING] Re: [PATCH] Revert "gdb: change blockvector::contains() to handle blockvectors with "holes"" Thread-Index: AQHcaG2TzHPp1ARtzkOM6k5Jjj4VZLUiphSA Date: Mon, 15 Dec 2025 12:08:06 +0000 Message-ID: <6cadb0cf3862706f4d70bb07a5002d8c99ea6906.camel@labware.com> References: <20251208180717.176567-1-jan.vrany@labware.com> In-Reply-To: <20251208180717.176567-1-jan.vrany@labware.com> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SA1PR17MB5365:EE_|CH4PR17MB7403:EE_ x-ms-office365-filtering-correlation-id: 844523ec-331f-4da0-501a-08de3bd29b2f x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700021 x-microsoft-antispam-message-info: =?iso-8859-1?Q?bqO5Auno0X5NuOhJpFOsI26sdgVatETxBrvVByzjR8bxB/CxMANBv+c+pC?= =?iso-8859-1?Q?5tPp7UbP5sxmn9SuBZlHxv1IzbU8ULMJxwQp2oD7DV2lQfKyVHTX/+JxLx?= =?iso-8859-1?Q?ewwTJhffmQZQCH52DQClQX9ddY5hD0/ym9slj6DT/EnraCymL0CNnhxeDJ?= =?iso-8859-1?Q?g0xsP8UaV64J9BjMzgA7d6Mo2ReW/htnYPlnPLfSi3sW0xo0ul6FqUbfxo?= =?iso-8859-1?Q?cC5DBCnK0ETOzcmza+X64OA6h/9SFZMvNlD4YnPIh99D55avilSZ4qfvpt?= =?iso-8859-1?Q?pzIcr3Nhp7C1TEa77DfvCA1nz95vUHrpFyfBVSP8c+h3yyIk/AY3FqV9xi?= =?iso-8859-1?Q?1DU4r1wRHADHIVT5W0kd0O9PWT/djQroUnJ9nUYgharwC2vskk4/8mdztp?= =?iso-8859-1?Q?opKE9WbvZkvh9jpkHfqHwSWMnL8Z7IIAzuUoJIs2Sg0tpP8Wmwu/cPb00w?= =?iso-8859-1?Q?CIePu4rN+OPS08lOa2Sz3KzoBFPfQ79uMagmfUi2C56g50/7HYyLGDtMo0?= =?iso-8859-1?Q?+S7c9xvJlTAuIDr/X7MsPf5VECpVWdlqchlBkDQFhHntHhNGbSk9juYytl?= =?iso-8859-1?Q?qTVRevCqLnMVsNaOLIBWu8fe3MB9NrirYGG92Y5Ui0rjh79qUms6BozBI9?= =?iso-8859-1?Q?RKrrQI109sbV06FFytEIrQy533bOjt9ozW37aTc2oBnE8xhech1XN5Eg95?= =?iso-8859-1?Q?VipGrKwxNHm1qkqJy9YdXTkmSzssCDb1QF5S/tpeUZzqHl0+v2tgWaZXgR?= =?iso-8859-1?Q?/w9jyyFoCA2KtTf2zXbL/hxNrn1sUqnmfhWjWn7zZwVBmkXG+ibtdw0Pao?= =?iso-8859-1?Q?0i0gkJ50JnEmcz/rsh2BELldqMzZYqqjNZAxELF7lFyjHsqA/KPiZ82kdk?= =?iso-8859-1?Q?sGQ0xzOsG8MdxCNDJRnsJipD2F7O9OojbJSS3xPaSCM98Xl7hbTk8x+YQs?= =?iso-8859-1?Q?sRbt2ghchF09VX2halyN98g2eH/+FN/Rp7iPx8GUQXy4tYYDtgQ4DuGmv+?= =?iso-8859-1?Q?CqSgklucKMNxSaAlSdwGo0sP78kWVfJCq+sE1WpE9+8BPzhXvxhEzsuKf1?= =?iso-8859-1?Q?moR7dVHE8RfW2ZJEeoskpLaMgP49/HDYDbGYHzFwQCc+/enuuAvE0tzWg/?= =?iso-8859-1?Q?AmWgppA4J9vW5MHMvKBwGCKQC1cEwLpuNBz1yo9OspnAKkDngZT/CqsV1a?= =?iso-8859-1?Q?fmDomnPreaw2dOYrWPmymdGaETbFrz5NnuUxjZTIuQq1CYhjdnPP+8EQYC?= =?iso-8859-1?Q?JM//eeGcSveMtCcRsxYFkK61RWz5+7b4MM9gywSP72eH/WAkPPW0DmUf0b?= =?iso-8859-1?Q?PduUiuybpObHH5OOtHBp3YsPgMZlwFI82Xy9K12Q+TuUgSw013QWXui3bm?= =?iso-8859-1?Q?ec/fQN/fyyUzxKpt2ipzCUDBAaCZv9n1XLMMy2NBn2iV/exzrnuY+0AkNp?= =?iso-8859-1?Q?VgulI01UlSfaqe1HncMKbAjbB298FTekrAquYrR90hYxaydIRtbR9t9D7E?= =?iso-8859-1?Q?Cxh53fUvPJvbe5PIqq46tiZ8eb68fj8nKKWTT3v67y3+6d0OQtSeh9Mpyp?= =?iso-8859-1?Q?ZvISoQQ2u6F/VpvYL5qWKE4zCMP3?= 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)(376014)(1800799024)(38070700021); DIR:OUT; SFP:1102 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?uYHrb2CMWfT+Sjkutxbt0OHTkdEvKxK90YwkueKE064gcREdVT1qy03Lbq?= =?iso-8859-1?Q?7aBn0+UX6dlkhtaaHyf2U0otaVOobJTBeWEAFwtmnOMvX86wCmqgNUtltQ?= =?iso-8859-1?Q?ePvEAhzVGA16I8Jd2eGftq3b7VWFBOIgFUIFb9TRA8hOsBfsjJAZh21QQl?= =?iso-8859-1?Q?qTPq/Mr2DFy2PYVwj7FmpU3dEQ9JzYD9dDk0VTvkVQG9iPRZ6uQWtpoFw5?= =?iso-8859-1?Q?1+KWpKgU7pDQSnqeW7tPcmsjvN8k0t+OPBnLtg7sNGm15Zq0euN1IOCeiR?= =?iso-8859-1?Q?N4AAbLBJXDGf8cItYovKcIpRaaqNNTujhFSka18V/JsU7QYX9XyLqQCZgL?= =?iso-8859-1?Q?br5Wlp5kTUwmI1P38kofI9149/aP5ZGIJwjfHczAjZXaF9T+KT10PEjuLc?= =?iso-8859-1?Q?1o47BxwBt/5+SegFFIMe9OgkJlUHwE4qs4r0szTcvlgyfSdZEP49bs0lrc?= =?iso-8859-1?Q?sxoXPtFxwWhOsrZNwGA8lwF4W5IGV38RgUjUZ+hvLoRfRycqJrHosXkemK?= =?iso-8859-1?Q?NUazZ6+fdaRInn3BYCB8Jo30Va7Den4XuvCxMM5hNYM9E4CKcpWddYoSMz?= =?iso-8859-1?Q?fewtSNd+jdNBJEGuyJPGnJ/DwNhIsZAiHV7Hk5PAM1GBieA9u4i8HQSYfg?= =?iso-8859-1?Q?78j8qmh9qGAozWaXQzr1KEALYhQaKRroNUfHZ9KhkcLTPIjQt02LzLnY1U?= =?iso-8859-1?Q?7spttLZ5lGFzP7qBY68MwcSLWp7w/78Ai8PZs2wNdu/nSMWVJ9vsysgoVT?= =?iso-8859-1?Q?kGmXyowUeoBZYJCPtpZQYmF8oG8vsWdsc4OVvsTKLpeDNmiIACVjtj7KzU?= =?iso-8859-1?Q?ZXTn385JUSUJ1G9F9hDAo4COtoG2xmCcYZc61+4HlfxII8/AwEzshcUoB3?= =?iso-8859-1?Q?en9HGJedej1wQvY0AxeWjg4fLbhJ78je1tYBJ4YxiIXhVZ31v9Kjc0GRvG?= =?iso-8859-1?Q?fWuxjH1juAK36JjXYR4xIKlFRS46a/v0uipfJU55b8jd+8UnA2wGvb+Z+L?= =?iso-8859-1?Q?/13p7OmOrFOZ21MbaG6a8KbScguXpb2X71cdC0ECvvGT/PlzAPqeKwVoMo?= =?iso-8859-1?Q?hAvxvaE7EOnu95Pmc1d+uGXVXfYAICqmS8TH3JSTqSDyPlTmTuRmb0yPDf?= =?iso-8859-1?Q?vNFp7iTxafE/eFy261lkEPSP2aTlwih7rpI675oKW7+Ka4dgqxFneAUySa?= =?iso-8859-1?Q?9W6Hnsdq5PaFgs0elnmU0Z4+jvQuXiFZoCkNrC0BPiIqxbY9n+5EHDos9y?= =?iso-8859-1?Q?LiB/AryNumUZ1UZQfuWJiJJVcSwZ62b0XDCnV9iIDIj/byHIOTvOqs7QAf?= =?iso-8859-1?Q?YsLJ5a5kReiRVxV1I8HH7OjdeiBJzQwaN4cD/vBnGnbptM7SBFvOz4+H0a?= =?iso-8859-1?Q?tjObqXiMb/4Lnq78FFnEdp3e3ScDGwK2iOUeC9fFnQrqj8Z0lXEg41x7vB?= =?iso-8859-1?Q?e4k8ixRCp00tV5dGBNsHAMxgagVVv3kXL7QO1Ey3sA5kaLhQJrl+s/5C20?= =?iso-8859-1?Q?GlxvoIikEpYfNd1GtP7PdjRe5tHvOzsBX1dgvl54BbSwdoDI0R8n0exVa3?= =?iso-8859-1?Q?ohGLx48N34wyS6kmtoUgAsyqwOKGV2MCzKEaA0k71QxDDwFCHfoDmXeIOa?= =?iso-8859-1?Q?D5ZifJT/dpGvltPC4OgoIBUJc8cOM/cOPK?= MIME-Version: 1.0 X-OriginatorOrg: labware.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA1PR17MB5365.namprd17.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 844523ec-331f-4da0-501a-08de3bd29b2f X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2025 12:08:06.5767 (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: Igz5GiWZHnJySdc5f1LHv6e5AqaqUGHz0DWK9s6E7umszpxtHGXv52QCCC+ruf5bArqNYAjhOiHI6G9uSz6t9Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH4PR17MB7403 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: bhp8PlwDnKBr3tCMHmii8CMoI6Ei2Dk6ftHIRXIYi5c_1765800488 X-Mimecast-Originator: labware.com Content-Language: en-US Content-Type: text/plain; charset=WINDOWS-1252 Content-ID: <30E5FC1A416F7D498A63B5DA8A99BD38@namprd17.prod.outlook.com> 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 Polite ping. Thanks, Jan On Mon, 2025-12-08 at 18:07 +0000, Jan Vrany wrote: > This reverts commit cc1fc6af4150b19f9c4c70d0463ff498703fb637, since it > causes a number of regressions that seem not to be easily fixable. >=20 > 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: >=20 > =A0=A0=A0 __asm__( > =A0=A0=A0=A0=A0 ".type foo,@function=A0=A0 \n" > =A0=A0=A0=A0=A0 "foo:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = \n" > =A0=A0=A0=A0=A0 "=A0 mov %rdi, %rax=A0=A0=A0=A0=A0 \n" > =A0=A0=A0=A0=A0 "=A0 ret=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = \n" > =A0=A0=A0 ); >=20 > =A0=A0=A0 static int foo(int i); >=20 > =A0=A0=A0 int main(int argc, char **argv) { > =A0=A0=A0=A0=A0 return foo(argc); > =A0=A0=A0 } >=20 > When compiled, the foo function has no block of itself: >=20 > =A0=A0=A0 Blockvector: >=20 > =A0=A0=A0 no map >=20 > =A0=A0=A0 block #000, object at 0x55978957b510, 1 symbols in 0x1129..0x11= 48 > =A0=A0=A0=A0 int main(int, char **); block object 0x55978957b380, 0x112d.= .0x1148 section .text > =A0=A0=A0=A0=A0 block #001, object at 0x55978957b470 under 0x55978957b510= , 2 symbols in 0x1129..0x1148 > =A0=A0=A0=A0=A0=A0 typedef int int; > =A0=A0=A0=A0=A0=A0 typedef char char; > =A0=A0=A0=A0=A0=A0=A0 block #002, object at 0x55978957b380 under 0x559789= 57b470, 2 symbols in 0x112d..0x1148, function main > =A0=A0=A0=A0=A0=A0=A0=A0 int argc; computed at runtime > =A0=A0=A0=A0=A0=A0=A0=A0 char **argv; computed at runtime >=20 > In this case lookup(0x1129) returns static block and, because of the > change in cc1fc6af4, contains(0x1129) which is wrong. >=20 > 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). >=20 > 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: >=20 > =A0=A0=A0 /* hole-1.c */ > =A0=A0=A0 int give_me_zero (); >=20 > =A0=A0=A0 int > =A0=A0=A0 main () > =A0=A0=A0 { > =A0=A0=A0=A0=A0 return give_me_zero (); > =A0=A0=A0 } >=20 > =A0=A0=A0 /* hole-2.c */ > =A0=A0=A0=A0=A0=A0=A0 int __attribute__ ((section (".text_give_me_one")))= __attribute__((noinline)) > =A0=A0=A0 baz () { return 42; } >=20 > =A0=A0=A0 __asm__( > =A0=A0=A0=A0=A0 ".section=A0 .text_give_me_one,\"ax\",@progbits\n" > =A0=A0=A0=A0=A0 ".type foo,@function=A0=A0=A0=A0=A0=A0=A0=A0 \n" > =A0=A0=A0=A0=A0 "foo:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 \n" > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "=A0 mov %rdi, %rax=A0=A0=A0=A0=A0 \n" > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "=A0 ret=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 \n" > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "=A0 nop=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 \n" > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "=A0 nop=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 \n" > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "=A0 nop=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 \n" > =A0=A0=A0 ); > =A0=A0=A0 int __attribute__ ((section (".text_give_me_one"))) __attribute= __((noinline)) > =A0=A0=A0 give_me_one () > =A0=A0=A0 { > =A0=A0=A0=A0=A0 return 1; > =A0=A0=A0 } >=20 > =A0=A0=A0 __asm__( > =A0=A0=A0=A0=A0 ".section=A0 .text_give_me_zero,\"ax\",@progbits\n" > =A0=A0=A0=A0=A0 "bar:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 \n" > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "=A0 jmp give_me_one=A0=A0=A0=A0 \n" > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "=A0 nop=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 \n" > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "=A0 nop=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 \n" > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "=A0 nop=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 \n" > =A0=A0=A0 ); > =A0=A0=A0 int __attribute__ ((section (".text_give_me_zero"))) > =A0=A0=A0 give_me_zero () > =A0=A0=A0 { > =A0=A0=A0=A0=A0 extern int bar(); > =A0=A0=A0=A0=A0 return give_me_one() - 1; > =A0=A0=A0 } >=20 > This when compiled with a carefully crafted linker script to force code > at certain positions, creates following layout: >=20 > =A0=A0 0x080000..0x080007=A0=A0 # "freestanding" bar from hole-2.c > =A0=A0 0x080008..0x080016=A0=A0 # give_me_zero() from hole-2.c > =A0=A0 0x080109..0x080114=A0=A0 # main from hole-1.c > =A0=A0 0xf00000..0xf0000b=A0=A0 # baz() from hole-2.c > =A0=A0 0xf0000b..0xf00011=A0=A0 # "freestanding" foo from hole-2. > =A0=A0 0xf0000b..0xf0001c=A0=A0 # gice_me_one() from hole-2. >=20 > The block vector for hole-1.c looks: >=20 > =A0=A0=A0 Blockvector: >=20 > =A0=A0=A0 no map >=20 > =A0=A0=A0 block #000, object at 0x555a5d85fb90, 1 symbols in 0x80109..0x8= 0114 > =A0=A0=A0=A0 int main(void); block object 0x555a5d85faa0, 0x80109..0x8011= 4 section .text > =A0=A0=A0=A0=A0 block #001, object at 0x555a5d85faf0 under 0x555a5d85fb90= , 1 symbols in 0x80109..0x80114 > =A0=A0=A0=A0=A0=A0 typedef int int; > =A0=A0=A0=A0=A0=A0=A0 block #002, object at 0x555a5d85faa0 under 0x555a5d= 85faf0, 0 symbols in 0x80109..0x80114, function main >=20 > And for hole-2.c: >=20 > =A0=A0=A0 Blockvector: >=20 > =A0=A0=A0 map > =A0=A0=A0=A0=A0 0x0 -> 0x0 > =A0=A0=A0=A0=A0 0x80008 -> 0x555a5d85ff50 > =A0=A0=A0=A0=A0 0x80016 -> 0x0 > =A0=A0=A0=A0=A0 0xf00000 -> 0x555a5d860280 > =A0=A0=A0=A0=A0 0xf0000b -> 0x0 > =A0=A0=A0=A0=A0 0xf00012 -> 0x555a5d860110 > =A0=A0=A0=A0=A0 0xf0001d -> 0x0 >=20 > =A0=A0=A0 block #000, object at 0x555a5d8603b0, 3 symbols in 0x80008..0xf= 0001d > =A0=A0=A0=A0 int give_me_zero(void); block object 0x555a5d85ff50, 0x80008= ..0x80016 section .text > =A0=A0=A0=A0 int give_me_one(void); block object 0x555a5d860110, 0xf00012= ..0xf0001d section .text > =A0=A0=A0=A0 int baz(void); block object 0x555a5d860280, 0xf00000..0xf000= 0b section .text > =A0=A0=A0=A0=A0 block #001, object at 0x555a5d8602d0 under 0x555a5d8603b0= , 1 symbols in 0x80008..0xf0001d > =A0=A0=A0=A0=A0=A0 typedef int int; > =A0=A0=A0=A0=A0=A0=A0 block #002, object at 0x555a5d85ff50 under 0x555a5d= 8602d0, 0 symbols in 0x80008..0x80016, function give_me_zero > =A0=A0=A0=A0=A0=A0=A0 block #003, object at 0x555a5d860280 under 0x555a5d= 8602d0, 0 symbols in 0xf00000..0xf0000b, function baz > =A0=A0=A0=A0=A0=A0=A0 block #004, object at 0x555a5d860110 under 0x555a5d= 8602d0, 0 symbols in 0xf00012..0xf0001d, function give_me_one >=20 > 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: >=20 > =A0=A0=A0 <0><71>: Abbrev Number: 1 (DW_TAG_compile_unit) > =A0=A0=A0=A0=A0=A0=A0 <72>=A0=A0 DW_AT_producer=A0=A0=A0 : (indirect stri= ng, offset: 0): GNU C23 15.2.0 -mtune=3Dgeneric -march=3Dx86-64 -g -fasynch= ronous-unwind-tables > =A0=A0=A0=A0=A0=A0=A0 <76>=A0=A0 DW_AT_language=A0=A0=A0 : 29=A0=A0 (C11) > =A0=A0=A0=A0=A0=A0=A0 <77>=A0=A0 Unknown AT value: 90: 3 > =A0=A0=A0=A0=A0=A0=A0 <78>=A0=A0 Unknown AT value: 91: 0x31647 > =A0=A0=A0=A0=A0=A0=A0 <7c>=A0=A0 DW_AT_name=A0=A0=A0=A0=A0=A0=A0 : (indir= ect line string, offset: 0x2d): hole-2.c > =A0=A0=A0=A0=A0=A0=A0 <80>=A0=A0 DW_AT_comp_dir=A0=A0=A0 : (indirect line= string, offset: 0): test_programs > =A0=A0=A0=A0=A0=A0=A0 <84>=A0=A0 DW_AT_ranges=A0=A0=A0=A0=A0 : 0xc > =A0=A0=A0=A0=A0=A0=A0 <88>=A0=A0 DW_AT_low_pc=A0=A0=A0=A0=A0 : 0 > =A0=A0=A0=A0=A0=A0=A0 <90>=A0=A0 DW_AT_stmt_list=A0=A0 : 0x51 >=20 > and corresponding part of .debug_aranges: >=20 > =A0=A0=A0=A0=A0 Length:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 76 > =A0=A0=A0=A0=A0 Version:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 2 > =A0=A0=A0=A0=A0 Offset into .debug_info:=A0 0x65 > =A0=A0=A0=A0=A0 Pointer Size:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 8 > =A0=A0=A0=A0=A0 Segment Size:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0 >=20 > =A0=A0=A0=A0=A0=A0=A0 Address=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Length > =A0=A0=A0=A0=A0=A0=A0 0000000000f00000 000000000000000b > =A0=A0=A0=A0=A0=A0=A0 0000000000f00012 000000000000000b > =A0=A0=A0=A0=A0=A0=A0 0000000000080008 000000000000000e > =A0=A0=A0=A0=A0=A0=A0 0000000000000000 0000000000000000 >=20 > 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. >=20 > Moreover, Tom suggested that the comment in find_compunit_symtab_for_pc_s= ect > (which led to cc1fc6af4) may be outdated [2]. >=20 > Given all that, I'm just reverting the change. >=20 > [1]: https://sourceware.org/bugzilla/show_bug.cgi?id=3D33679#c13 > [2]: https://inbox.sourceware.org/gdb-patches/87cy6xzd3j.fsf@tromey.com/ >=20 > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=3D33679 > --- > =A0gdb/block.c | 29 +---------------------------- > =A01 file changed, 1 insertion(+), 28 deletions(-) >=20 > 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 > =A0bool > =A0blockvector::contains (CORE_ADDR addr) const > =A0{ > -=A0 auto b =3D lookup (addr); > -=A0 if (b =3D=3D nullptr) > -=A0=A0=A0 return false; > - > -=A0 /* Handle the case that the blockvector has no address map but still= has > -=A0=A0=A0=A0 "holes".=A0 For example, consider the following blockvector= : > - > -=09B0=A0=A0=A0 0x1000 - 0x4000=A0=A0 (global block) > -=09B1=A0=A0=A0 0x1000 - 0x4000=A0=A0 (static block) > -=09 B3=A0=A0 0x1000 - 0x2000 > -=09=09=09=09(hole) > -=09 B4=A0=A0 0x3000 - 0x4000 > - > -=A0=A0=A0=A0 In this case, the above blockvector does not contain addres= s 0x2500 but > -=A0=A0=A0=A0 lookup (0x2500) would return the blockvector's static block= . > - > -=A0=A0=A0=A0 So here we check if the returned block is a static block an= d if yes, still > -=A0=A0=A0=A0 return false.=A0 However, if the blockvector contains no bl= ocks other than > -=A0=A0=A0=A0 the global and static blocks and ADDR falls into the static= block, > -=A0=A0=A0=A0 conservatively return true. > - > -=A0=A0=A0=A0 See comment in find_compunit_symtab_for_pc_sect, symtab.c. > - > -=A0=A0=A0=A0 Also, note that if the blockvector in the above example wou= ld contain > -=A0=A0=A0=A0 an address map, then lookup (0x2500) would return NULL inst= ead of > -=A0=A0=A0=A0 the static block. > -=A0=A0 */ > -=A0 return b !=3D static_block () || num_blocks () =3D=3D 2; > +=A0 return lookup (addr) !=3D nullptr; > =A0} > =A0 > =A0/* See block.h.=A0 */