From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id WKBnOzKeCmYv4x4AWB0awg (envelope-from ) for ; Mon, 01 Apr 2024 07:44:50 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=HOTMAIL.DE header.i=@HOTMAIL.DE header.a=rsa-sha256 header.s=selector1 header.b=t5OeNDJ4; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id EDDED1E0C0; Mon, 1 Apr 2024 07:44:50 -0400 (EDT) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (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 DE6031E030 for ; Mon, 1 Apr 2024 07:44:48 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 850B93858417 for ; Mon, 1 Apr 2024 11:44:48 +0000 (GMT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04olkn2081.outbound.protection.outlook.com [40.92.73.81]) by sourceware.org (Postfix) with ESMTPS id D81573858D34 for ; Mon, 1 Apr 2024 11:44:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D81573858D34 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=hotmail.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=hotmail.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D81573858D34 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=40.92.73.81 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1711971863; cv=pass; b=YCDu+lCyywRe921txrtk+mUS/WoysnlfiTh+x8qjgLfcOH7kDWK3fBR75q6wtBU7WhLQfkKRi6cyXnW4LYdOW+DWpp7YIcecbqgexZKx3nQFRv8G4B7h5NH9uVzFpj3/Z2/T7BUQBYr1o5Jju5nkPFTgT4NQaP5QATf6dQVlQFk= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1711971863; c=relaxed/simple; bh=Xm5xVSLqJEx6o3XYRjf6K5Dfs6hH1GwA8ZWEjEp2Ei8=; h=DKIM-Signature:Message-ID:Date:Subject:To:From:MIME-Version; b=t+fwfYw6HIslOhuJzjaKE5eKaDdbEmjnUDShJbMRczNA1P8VD9S/jNmc4Bop7geyD3Z30PN2FiCY/IS41NzNTqKBqlHJJ8+TfrvMtvXLaKECp24QcELQAujGeMxcTCV5eu1Xncu9SrUEDIW7jniClH8oFMKelyhMtkqVkm542WY= ARC-Authentication-Results: i=2; server2.sourceware.org ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DjQu8waSIp1AqW92xJFsYbfzfyNUROYA7uebeNwXPNUr6Zqm+rwMVUj6HDuKv6YVV93mckXHBNKlwsX2XfB7GG35nJxOJuCMmtnB4ZPQoauDneGmcdkp1vKChi825mazXZ+sS+mAni2V8JmgtKDnHz22FbgxOmY3Sm4UJPMZaRiBe171V374WvhlrgSERPgODqFXdihpUag7vM0TgpOfYDnh+HfZu5NYH5YQh/MbCScFDq3Nh5PY5sEV36Sd8GEvSDTjqyx9kpS04ruFJnxfduk6nNwv3TtsvkoZayPfbowtU37bMJ5UpbOwXXqIjmo2lMf7JmTKfEBq4+UYsz9Fkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7/xJWdPCEutbm4P8Y9nCqZLFWYadXWgmEsFNzzDvrJY=; b=mDWYMWOxBq6jrWOlUXkNki1ihWmByhuWBHBaUmB6ceUcx+ThXpwRAiLAbfIHihyo0E+3pdFRqqg89qNIo/fV3z28TI/ghpIe6TK+EFoC4GQVZVF5HIyg5AViDXrUSIU/ca17s2KX3EIvn1spiLd4UMotOLmjDrkl/MENOAsKIGQCh8349KQvfBAMzpR35/Yh/D4cHPPspUYg0OjJztYbBzNrG7t87PYW/WrDFDPXn+azH/B1dMnmlVGUqFmEdfHKJOLdX48TMbJOAncaFSQlqPK0g6AWU2aR76EiMQhTCKHkBz2paxeaEMCa5o5vYX1ADQ6mJQsmXzZEBE7LQuebig== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=HOTMAIL.DE; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7/xJWdPCEutbm4P8Y9nCqZLFWYadXWgmEsFNzzDvrJY=; b=t5OeNDJ4p+14guO9qX/ruiYjmimhHnIaWVtIKX06bVGNCapi6s7ILYmjf5mCWHs3GG+TnXPLZ7fpZxncoroocZ7Tr/eDA2FmhJ0lRCWElUdx/Mf4WS6NBA+rY1ch71AwAnLLh56iM61EHQMpCcRajJM+ZKquuiaZoA7hJM2b6wSAJTE0KhBFB1fY+oiNjSmVBoh5viFgxZ1Qja/D3UHsujJF3NXoqC+OIetY3530z4LkU6XwfFTE3sr1MK3+hZaWCspE13PegDjVbUbm8gq63mOtq/oxdzDlxvP6616JlSgiqGVt5DFItDLaf51qBtYs/tFW7clSSlXEeDVgMENZ2A== Received: from AS8P193MB1285.EURP193.PROD.OUTLOOK.COM (2603:10a6:20b:333::21) by DBAP193MB0937.EURP193.PROD.OUTLOOK.COM (2603:10a6:10:1b5::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.46; Mon, 1 Apr 2024 11:44:10 +0000 Received: from AS8P193MB1285.EURP193.PROD.OUTLOOK.COM ([fe80::5403:f1ad:efaf:1f71]) by AS8P193MB1285.EURP193.PROD.OUTLOOK.COM ([fe80::5403:f1ad:efaf:1f71%4]) with mapi id 15.20.7409.042; Mon, 1 Apr 2024 11:44:10 +0000 Message-ID: Date: Mon, 1 Apr 2024 13:45:53 +0200 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Remove unnecessary get_current_frame calls from infrun.c To: Simon Marchi , gdb-patches@sourceware.org References: <66c53f57-006a-4a2f-bce7-bb04d7b58566@simark.ca> Content-Language: en-US From: Bernd Edlinger In-Reply-To: <66c53f57-006a-4a2f-bce7-bb04d7b58566@simark.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TMN: [am03GFc3ywWSqewGXQOpYEqgvEm2AeNL16yLktkg7p9DwA1L5WC2A/CKohn8xkyc] X-ClientProxiedBy: FR2P281CA0046.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:92::20) To AS8P193MB1285.EURP193.PROD.OUTLOOK.COM (2603:10a6:20b:333::21) X-Microsoft-Original-Message-ID: MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS8P193MB1285:EE_|DBAP193MB0937:EE_ X-MS-Office365-Filtering-Correlation-Id: 0fb5f13c-5a7a-4ab5-abc9-08dc52410b10 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: dL1qI3mVujBhN2WgFgvzskmq88eh6be/Tbrr4TQw1UMQ0zvvCq7GIaQ15uT/L63Wl+8aozS2Rr8eu86qVgIiFHjLcNJ+xQ38Py4ZcOpFd+S/lwi9EU28lVsplMYBVMe38VKkwmnFguiHTH1wg90bMqLKc8qLQQZpzUZxdS+4QIlCw3m69AAZzViRou0tx8kRjOl0Rog4bIhv48W3yXTqExpGjliz0+JTnnZGAWXUiRsVdAXmJmvkVww9GorCu6hzT61JFfsxD15HzsKatY0LWDFfVio9u5d3IENindCEmKFq0PJNjWjJ23HeAVRSmSyQWY+aaUYItB+6+uHzOpdBmXQ+2p/fxPgB9lRJ4i8DaOf0fIHRDUIXImJaYBH0O7j0fjwQW1gM53c7B38YGqzYIg6z4eall9J7xiNhHidO/l14yEu/KIIRrdlMCu4JghI4MI2jvAIwHNvLr+HYj2Q6++uTf7YxlAK+GBSJBob3NaWXFojX/LdCUHAABhjj562ENYuCCnxqtTSfVxWBD6YyR24PNx0spnppR0c5s3mRZnwJaEzv39RyiEQjnGNd+tXA9BQYpnUnen6wRXCtqqkiPZElLOl0PPjO03wB7N/R6Vo5kUHn68qLmNBTWek2VshCjzDC4YY26kvKwrQHarapMo+huFTlodtYWooF/VEoJtw= X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dTBIZ1lINE9SREpFd1FaWUdKamlLN2RsK2IzM0lVa1RGdi9MT1A5Smt3OXQ5?= =?utf-8?B?cHB2NWlJVTR1WG1IaGVYd3QrOEdDTDRpRlcvZlQ2TDBjUjFLdEhOdWZYUm1s?= =?utf-8?B?cEtCU1N3Wnh0dk05R1J0RGZ2WkszM1BoelpQSEpwSHRBWWRtK2orTVZrMUJF?= =?utf-8?B?eU5GbkhXRFRKRytTWjRZc29obHdQUERLUWRlRDRaMGxjTU1KOCs1OUFoZkVr?= =?utf-8?B?Zk9BRGk5L3ErTUljZEl0ajlHUnNZTStxanhRcGtGR1M3eERueDRZODIvK05u?= =?utf-8?B?SEUxb2tMY2xzZXVOREdHNEt5SUpJengxNEp2ckZDLzh1ank4d3dnVTloVy9i?= =?utf-8?B?Rkg4VHNIYUJOUmVobmMxVXBHOTRSVklTcldHTlQ1T29hMzF0N0R3QWI0VHk0?= =?utf-8?B?MG9lNkhBMVBmTnNBbHBKZkFtb1czRE9qMzlLSWtuTlNZNTlFc0l0TkR4bTh6?= =?utf-8?B?OXV1RHlOUnlaRDU4N2U0S2NSL0NmUkNucGI2ZnVKYXVoQjNiVmpKQklTSzMv?= =?utf-8?B?eFJSUGpVWTR2S1RaWnpxNG5XNWNUTkc5QnY0OUZSZWdGaGxwRDBVY0hIbHNK?= =?utf-8?B?ZXp4ME5rV2ppUUs2Y2tkbStmOFpOVnlqMWlmRmh0TTVrS3o4Y3BMZkUyOVR5?= =?utf-8?B?aFBKWjNxRURwWlhad1dETm9tVlg1bHgrUXJjKzkzektpVytpZGR4S2tiR3hy?= =?utf-8?B?VmpBQ0FpLzBWbmJIM0NWdTBjc2RkMXoyTUFwVTY3aU1iQ0w3OEFBbEZYa2My?= =?utf-8?B?aXZ0eTQwODFRUXhzRGxiUk5vZFdIck8vTC9kTm90SlBxV1F0SDVldGZDVWpU?= =?utf-8?B?NHdxc1hMR3M3cnZGL3BTemdNUjVvWTNwbGpnTk1LWUpFT1RSOXhsNStWM0pM?= =?utf-8?B?QlRPbk9zbWVEMk1aZm80ZUpLSk9OdDcxbk9pTDY5c1BHK3JFMlU2a1JhYkdu?= =?utf-8?B?enZJNFplbFpDOW9iRVQzZ3M3c3YvRlJBWS8yTlJCQ2ZYQnVYL3hKcEJsYkdX?= =?utf-8?B?RU1lS3VDVEFTRDh2T1RiSUtsdVlxYjFQejhFdFJ3Rnk3NlpqTUE2cEpDRGxS?= =?utf-8?B?TzY2dzNQcTdpaU5IaHFzS1cvdTFkNDFKTy83azhFdHdvdTZ1UE02c1EzNDZM?= =?utf-8?B?d2VmRW1hMVRUcFY0b3U1aWRucVF1cFdEb2d5bHQ2SmRWek0vaUJ5bEtUb0Z0?= =?utf-8?B?Mkh5cEpBVWlpVFM3c0I4ejFuMStrNnZxSjdOelVGNjlydytoU0pmU1dRNDht?= =?utf-8?B?N1Y2b0hQTjQwM2Y1dzJwaVJNUkVSWUpUOUo2dlJQcVB6QVdVRmVLbThEOGxQ?= =?utf-8?B?QmZ6WEFPTVJ1aFJGYnJvNXRBMXI2eW1PdlpJcU1RcUlEbVFSczFyd2MvSWZq?= =?utf-8?B?eUZNMjlXdk9VcUFiRmtSZTdCbG96TU5qcXNMTmg5VDNSQ2tqN0dEem9tSm1r?= =?utf-8?B?Y0wvMjNrZ1puTUdtUGlMV0dXOGVtZ3BHYms3N1BQVWRveCtxSEZhdGNBODZk?= =?utf-8?B?dURWZllDMkYxZE5uY09ubkNWbm9rVEQ4TE1ndU1WVHFuaG44NFJJS1hYV29N?= =?utf-8?B?U211ekpLMTdLeGRBYkNETUU1NGg5M3dLR2d0ampMb0NOU1orQ2I5Vld6UTMx?= =?utf-8?B?SkJQM0h3Z0JoU0ZEallIbi9hUjZKczJaNzVnTnk1Kzk5cFdOSnI4VXNpNS94?= =?utf-8?B?VjViWW1VeXhBWlc1ZnBHNGgwVG04S3VDVVdvbGNDSHZHRXZvYVhNZ3NGU2ZG?= =?utf-8?Q?97fX7RKAR1rj2+HMyN9Iw0I7YAydXZMNi4kueZ9?= X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-80ceb.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 0fb5f13c-5a7a-4ab5-abc9-08dc52410b10 X-MS-Exchange-CrossTenant-AuthSource: AS8P193MB1285.EURP193.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Apr 2024 11:44:10.0784 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAP193MB0937 X-Spam-Status: No, score=-14.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org 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 On 4/1/24 04:52, Simon Marchi wrote: > > > On 2024-03-31 06:50, Bernd Edlinger wrote: >> Since the frame variable is now a frame_info_ptr, the issue >> with the dangling frame pointer is apparently no longer there. >> >> So remove the re-fetch code and the corresponding meanwhile >> misleading comments. >> --- >> gdb/infrun.c | 24 ++++-------------------- >> 1 file changed, 4 insertions(+), 20 deletions(-) >> >> diff --git a/gdb/infrun.c b/gdb/infrun.c >> index a5030b16376..521c3b0299c 100644 >> --- a/gdb/infrun.c >> +++ b/gdb/infrun.c >> @@ -7056,11 +7056,6 @@ handle_signal_stop (struct execution_control_state *ecs) >> ecs->event_thread->stop_pc (), >> ecs->ws); >> skip_inline_frames (ecs->event_thread, stop_chain); >> - >> - /* Re-fetch current thread's frame in case that invalidated >> - the frame cache. */ >> - frame = get_current_frame (); >> - gdbarch = get_frame_arch (frame); > > For `frame` I agree, I think we can remove it. But I'm wondering about > `gdbarch`. Before we had `frame_info_ptr`, even if `frame` got > invalidated, it didn't seem necessary to reset `gdbarch`. Are there > cases where you would get a different value for `gdbarch` as it > currently holds? I can't think of any. I'm leaning towards saying that > this is fine. Yes I was not sure either, and I tried first to add those assertions gdb_assert(frame == get_current_frame ()); gdb_assert(gdbarch == get_frame_arch (frame)); gdb_assert(*curr_frame_id == get_frame_id (frame)); since I had previously learned the hard way what could happen here. All those assertions did not trigger anywhere in "make check-gdb" But gdb_assert(frame.get() == previous_frame_get_value); did trigger at various places. > > This is the patch that introduced it, if you want more context: > > https://inbox.sourceware.org/gdb-patches/alpine.DEB.1.10.1206121703180.23962@tp.orcam.me.uk/#t > Yeah, reading that it sounds like the author did mean that he was not sure if the gdbarch is still valid or not, but it would look odd to refresh gdbarch here while not refreshing frame. I guess gdbarch objects they are more or less static by nature, but I was curious as well to find where they do actually come from. I think there are only very few different values of gdbarch possible here: My experiment below shows there are only 3 objects ever allocated (for x86_64): diff --git a/gdb/arch-utils.c b/gdb/arch-utils.c index 456bfe971ff..30207db9694 100644 --- a/gdb/arch-utils.c +++ b/gdb/arch-utils.c @@ -1233,6 +1233,7 @@ gdbarch_obstack_strdup (struct gdbarch *arch, const char *string) void gdbarch_free (struct gdbarch *arch) { + printf("free gdbarch=%p\n", arch); gdb_assert (arch != NULL); gdb_assert (!arch->initialized_p); delete arch; diff --git a/gdb/gdbarch.c b/gdb/gdbarch.c index 9319571deba..79e8dcec122 100644 --- a/gdb/gdbarch.c +++ b/gdb/gdbarch.c @@ -278,6 +278,7 @@ gdbarch_alloc (const struct gdbarch_info *info, gdbarch->byte_order_for_code = info->byte_order_for_code; gdbarch->osabi = info->osabi; gdbarch->target_desc = info->target_desc; + printf("gdbarch=%p\n", gdbarch); return gdbarch; } One of the 3 allocated objects is returned from get_frame_arch every time. And since the gdbarch_free function is apparently never called, there are probably memory leaks somewhere, which wouldn't surprise me. Bernd. > Simon