[PR,gdb/29272] Make sure a copy_insn_closure is available when we have a match in copy_insn_closure_by_addr
Message ID | 20221026084100.28009-1-luis.machado@arm.com |
---|---|
State | Superseded |
Headers |
Return-Path: <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 05CFF382DE46 for <patchwork@sourceware.org>; Wed, 26 Oct 2022 08:44:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 05CFF382DE46 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1666773881; bh=cwhxmHbdHw+NXxniIaQntqnSOGMdRR0JD/LFMyIVNT8=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=FFsBPHu0iezFy6KLQL0lgMJ1TVT0ZSkzaUh+pXbWJZPTyRY0GTbJQt63zRQd43qoL /ho/5BcZXnlNeY4eED4rASkn3AIuYazq3dnHqBKDXdZ8uB9ipTmloPZ9WpBNbRkWk4 BAS8RhR/AM45uhKaW76hhNzAArJGh57Bddt/l6Xc= X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70054.outbound.protection.outlook.com [40.107.7.54]) by sourceware.org (Postfix) with ESMTPS id 2F92B395250C for <gdb-patches@sourceware.org>; Wed, 26 Oct 2022 08:44:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2F92B395250C ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=Em0/4iWnzXpoJODuUTiSUkGihM5Kcgcfug5RlVIDcPcq6v3zFIyqE4FpimhGbZPcm/H/x20k3ms2QmkhBsISF61C4Lt4Bvw7cvFbAOoIR7/QdqQXPh3m2WUpHJIgSPuioTNvffIgP+jk0Subzl/4MqmJwyzvVpNTfbCV+D9LgAQGnSqBNzdD+OScyQRvHQkaIqcR6vd/j1mXGjhtYOeezNgpfrpIgyc6GjoyJQQhy3ZZoXIK9X+P3VEsDUxqzNcmbFynf0fe3AfldO3u/Y4ISaAlmJrVHPFu19Cv6Ainm2LB8CyJpE9elgiIOfbG5zmjTCMJjfYd8u7y8PlcGDqfXw== ARC-Message-Signature: i=2; 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=cwhxmHbdHw+NXxniIaQntqnSOGMdRR0JD/LFMyIVNT8=; b=dIW5tW3D1d1a5hjKm2Xh+3IIxbAstyy4l2xRgh7zkRqowTAACtIpwJgyVvEkikYch4GeZ4CJVOWhZ/tIXoRi8+Ir6IAeQeLg+13BJesNApq2p4O8aPB3TfhL3fwsOjdr1qS1HZQJruGxmE8Fy18nhMm2kzJGFhULC+32SaH+i7567Eym+NegiWNsZGOdwKkWpItxJGmSm5IquhzBXxfBfyxN87gOveHPXNWc6/jnWnzui/NLZi9mdQtq49p5c8fr3dw6Wmn6ee+Bz5gd1gNVDv1Guxcu7f9fvKqqNjE8ecSOXY/+7e8+Sd1KysaYN9fDBC2YAca/KLGX8kQWP3fUQA== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=sourceware.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1, 1, smtp.mailfrom=arm.com] dmarc=[1, 1, header.from=arm.com]) Received: from AS9PR07CA0016.eurprd07.prod.outlook.com (2603:10a6:20b:46c::27) by AM8PR08MB6627.eurprd08.prod.outlook.com (2603:10a6:20b:368::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5746.26; Wed, 26 Oct 2022 08:44:09 +0000 Received: from AM7EUR03FT011.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:46c:cafe::2d) by AS9PR07CA0016.outlook.office365.com (2603:10a6:20b:46c::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5769.12 via Frontend Transport; Wed, 26 Oct 2022 08:44:09 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM7EUR03FT011.mail.protection.outlook.com (100.127.140.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5723.20 via Frontend Transport; Wed, 26 Oct 2022 08:44:07 +0000 Received: ("Tessian outbound f394866f3f2b:v130"); Wed, 26 Oct 2022 08:44:07 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: f03c48cb1f983c56 X-CR-MTA-TID: 64aa7808 Received: from 8f2adc393f6d.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 9E0B84FE-0637-4EAA-A64E-ACB122B3C208.1; Wed, 26 Oct 2022 08:41:08 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 8f2adc393f6d.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 26 Oct 2022 08:41:08 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HO+r7W2yOaiXDiNNav5ztT8McMQh6wDFJ93081JgP8/Nm1cpJUjEI6NaFFr53FZ2R5kTdPGLHTLNCVxycI+Yqrg0OEcVdWXgiBJrKDOy2Pcv+hWEOuhXdnzxm5nrcOZzcpOUZBGltRhLjemLVZ/YzgdejzwEumgwyUY/ZafBY5xoGcj5xYHaQKbPZD65YKheCwiqzhdpAgk4deoV9XgdJb0z5ppLhzBNPt3vFt/xPoOPGS9ZIpZWAzCpP4+pMsR8TJjvRkFx6jHS2ZQIgmPGuT7V3AQsnRoN7nGkRnc5+rfvRnJMyKTJpfErSl7F5J8hfACQKeo9ixx+oZPSn453BQ== 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=cwhxmHbdHw+NXxniIaQntqnSOGMdRR0JD/LFMyIVNT8=; b=SBEgvyHeVzGYDSaEfTppmckSV3uKsGlSr01X5i9bK6hRSV33RZIIa2J/GH302VURfPtZAlEE9at6INI88NIx8AMvUwYykuU2GzhshYy4h9JokABigFo2+1sdhutukocb9/pVdiM96fVWXkyFdWqIDPNBBk3xFwiT0ntZNJzaoSkkF9/ErnCWyqjP5V0JrB9KZhyCDqQQrVQYTkfj3yvOWDQoNkn9vERHUjLcRwXn53d5Cuv3TA1vuwSfWQMwtX34Uzh/8G7vEfkRxiKAERCSsH3BbzvEuqSVo9WONcSzNz0BpmysNJnAxudG6XfisVUrayBbOPnuub3fwwMIwMtVqg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 40.67.248.234) smtp.rcpttodomain=sourceware.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=none (message not signed); arc=none Received: from DB8PR06CA0054.eurprd06.prod.outlook.com (2603:10a6:10:120::28) by DB5PR08MB10253.eurprd08.prod.outlook.com (2603:10a6:10:4a9::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5746.21; Wed, 26 Oct 2022 08:41:06 +0000 Received: from DBAEUR03FT005.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:120:cafe::d4) by DB8PR06CA0054.outlook.office365.com (2603:10a6:10:120::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5746.28 via Frontend Transport; Wed, 26 Oct 2022 08:41:05 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 40.67.248.234) smtp.mailfrom=arm.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 40.67.248.234 as permitted sender) receiver=protection.outlook.com; client-ip=40.67.248.234; helo=nebula.arm.com; pr=C Received: from nebula.arm.com (40.67.248.234) by DBAEUR03FT005.mail.protection.outlook.com (100.127.142.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.5723.20 via Frontend Transport; Wed, 26 Oct 2022 08:41:05 +0000 Received: from AZ-NEU-EX04.Arm.com (10.251.24.32) by AZ-NEU-EX04.Arm.com (10.251.24.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.12; Wed, 26 Oct 2022 08:41:05 +0000 Received: from e129171.arm.com (10.57.67.40) by mail.arm.com (10.251.24.32) with Microsoft SMTP Server id 15.1.2507.12 via Frontend Transport; Wed, 26 Oct 2022 08:41:04 +0000 To: <gdb-patches@sourceware.org> Subject: [PATCH] [PR gdb/29272] Make sure a copy_insn_closure is available when we have a match in copy_insn_closure_by_addr Date: Wed, 26 Oct 2022 09:41:00 +0100 Message-ID: <20221026084100.28009-1-luis.machado@arm.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 1 X-MS-TrafficTypeDiagnostic: DBAEUR03FT005:EE_|DB5PR08MB10253:EE_|AM7EUR03FT011:EE_|AM8PR08MB6627:EE_ X-MS-Office365-Filtering-Correlation-Id: bf618d60-9b72-4137-305d-08dab72e3efe x-checkrecipientrouted: true NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 8PBv3fgtTAx4amK9Vy/JM6eF5HC5RS5TCFC7V29kThF4b4laR2tX3f6X5FdPepWaH9IftPJ87k4TaFK1+V+fAPKYZ1hQsdwJuBNl2qGYsNXPHN/DgwCUzItqCK48UHup3BvG9F8c0Iz68Dsjiqsjl/7sUBjrHGwlK8OmmV2VpEhZ75DoY+ocqRjzSktw0Ocea9yAsav3vnoR3Sh6hqQj8Bt8jnKZd8tE1JSCOKSUsCIrp1YP0orSYDF+a9y6Q0TuVq6UNuJRkGojC1tGs09dj5yyuhAQDFisB3z09DxBrR/Sx2seo4+1b5Mb7SuxEJiqlC5N1Ii3XF25/P1y4wIut4v2Um+Z+0t3sDrQ+WHx8Cw94YCjqKuQIPT5wuc9bHdAx10phE1kRqVosZ7L1uwmJBFpwJ9DFjG8esJ0gS3DngtO0GLoZKe/QFKEcKOf45I7NCqEu4DcMfA+v9DkRrNT/u5WYSV2dEYckV5c7upi9PUwbXGYSFYlVKqBoUPEsGRupReszaWqml1tDSnrcAK0WLI5NBgtXt1NruSbOtLuku+Sg/eZKwjjno00cFANh5ISupO3uy0gtzTsg19N9r6qpqSV5EIfxlyaqs16Efrp6co8xDoZPCQaItHgoWlEFUSGqDiA4uRX2rUEPIXfR/b1yMOxQySaHd5lk9IFEGFIokQok4tUWIDfeBeJKN8JDOj0N083sbNerl00nFk/jhr+Wi8FcIMfdm6psyXyFkIBeoZBmxt4ZVrXYjx0J7RG3dDdLHt85s+9OASUw3rvaor1z+N3/OkS+Xp+32WfOtx8uERkBBcW4cXNaZ8MsXP4rnsGdI1zKmk6A4HIDTXzpEyFXQ== X-Forefront-Antispam-Report-Untrusted: CIP:40.67.248.234; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:nebula.arm.com; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(13230022)(4636009)(376002)(39860400002)(346002)(396003)(136003)(451199015)(36840700001)(40470700004)(46966006)(2616005)(83380400001)(426003)(336012)(8936002)(186003)(70206006)(47076005)(5660300002)(4326008)(44832011)(70586007)(6666004)(82310400005)(1076003)(41300700001)(7696005)(8676002)(40480700001)(86362001)(478600001)(40460700003)(356005)(316002)(2906002)(81166007)(36860700001)(966005)(36756003)(26005)(6916009)(82740400003)(36900700001); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR08MB10253 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM7EUR03FT011.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: d5c22b35-4879-447b-aae8-08dab72dd27b X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: B5UARqI46DOLpJ+EEdJpxOeoYSQvvt0yaZtPU1lGYRwu6757Klrn8h86CZzAjx5eJuQwcq2Cb5aLgdDuJfKxLOO8z29Z38ay2YWsFJgow10wUy6qsMAoU7RdwFljUzISWx0HTBRzJO2SLpEVXbos7fUFuVgTBQZj9R64FYcEyGF8Es2tAqDWZoNqr09OVT/da6qPR/ghlxRjGXQLvgTi8M8hxxYneAZSSwFQV87l8mVcCGAAbCJcNI9JleuYFdDTipriCeAS9k5KnQLFX+xnR/84j4sdY+OJCUlv6tO59Lglzsk8PCcO/++DX45Q2dhcswtSZNb07hOmNtry3qEPGZOw4ZP6q1EyVEkBqdYJcOKU6arYlZZPxwmmABoQQujXmIrzEmxaJTB3naozIWWhhNNYDnh0tff7RD72u85pjeNPHFaev2ri9gETfKRV1uvJy6jZK7SJw5Y4vqb3XjxMGU2fuuWf58Uy18ceYRVjaMou/oBZGPiiZc4NTVWics6rJPaIfY/zxCxZbOZO/kCdGEUM0ae8fDS89T4ex5J2bvEKRcWYVpJoc/Bq44w+K4bxs9dbjCoqXWC5G+pBvXCT+JtVVDHNtGuHtePVSiG/XiIzS4+RmOGAHGhPGWQfkL+lZWBaqiZ0vCEicniHgWnA6iyPVRIL7iUkeKePtHpBbtRkWMa09gLy7taj5kiqlFV5BaDnHPCGUrdj53PPNhUFLrDQXF8YVm1CBnvyfZqM5sNgsotXyTClLyPWxiLuIyuuvNwrAXSx1b3AZUFVyVmfWoLgrvMBtG+G6OWXuxqi8Lo= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(13230022)(4636009)(376002)(346002)(396003)(136003)(39860400002)(451199015)(40470700004)(46966006)(36840700001)(426003)(83380400001)(86362001)(36860700001)(82740400003)(8936002)(47076005)(5660300002)(70586007)(70206006)(44832011)(40460700003)(41300700001)(1076003)(4326008)(8676002)(81166007)(6666004)(2906002)(7696005)(186003)(107886003)(26005)(2616005)(6916009)(40480700001)(336012)(316002)(966005)(478600001)(82310400005)(36756003); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2022 08:44:07.8946 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: bf618d60-9b72-4137-305d-08dab72e3efe X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AM7EUR03FT011.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR08MB6627 X-Spam-Status: No, score=-12.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, FORGED_SPF_HELO, GIT_PATCH_0, KAM_DMARC_NONE, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_NONE, TXREP, UNPARSEABLE_RELAY 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.29 Precedence: list List-Id: Gdb-patches mailing list <gdb-patches.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=subscribe> From: Luis Machado via Gdb-patches <gdb-patches@sourceware.org> Reply-To: Luis Machado <luis.machado@arm.com> Cc: simon.marchi@efficios.com Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org Sender: "Gdb-patches" <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> |
Series |
[PR,gdb/29272] Make sure a copy_insn_closure is available when we have a match in copy_insn_closure_by_addr
|
|
Commit Message
Luis Machado
Oct. 26, 2022, 8:41 a.m. UTC
Investigating PR29727, it was mentioned a particular test used to work on GDB 10, but it started failing with GDB 11 onwards. I tracked it down to some displaced stepping improvements on commit 187b041e2514827b9d86190ed2471c4c7a352874. In particular, one of the corner cases using copy_insn_closure_by_addr got silently broken. It is hard to spot because it doesn't have any good tests for it, and the situation is quite specific to the Arm target. Essentially, the change from the displaced stepping improvements made it so we could still invoke copy_insn_closure_by_addr correctly to return the pointer to a copy_insn_closure, but it always returned nullptr due to the order of the statements in displaced_step_buffer::prepare. The way it is now, we first write the address of the displaced step buffer to PC and then save the copy_insn_closure pointer. The problem is that writing to PC for the Arm target requires figuring out if the new PC is thumb mode or not. With no copy_insn_closure data, the logic to determine the thumb mode during displaced stepping doesn't work, and gives random results that are difficult to track (SIGILL, SIGSEGV etc). Fix this by reordering the PC write in displaced_step_buffer::prepare and, for safety, add an assertion to displaced_step_buffer::copy_insn_closure_by_addr so GDB stops right when it sees this invalid situation. If this gets broken again in the future, it will be easier to spot. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29272 --- gdb/displaced-stepping.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-)
Comments
On 10/26/22 04:41, Luis Machado via Gdb-patches wrote: > Investigating PR29727, it was mentioned a particular test used to work on Typo, 727 <-> 272 > GDB 10, but it started failing with GDB 11 onwards. I tracked it down to > some displaced stepping improvements on commit > 187b041e2514827b9d86190ed2471c4c7a352874. > > In particular, one of the corner cases using copy_insn_closure_by_addr got > silently broken. It is hard to spot because it doesn't have any good tests > for it, and the situation is quite specific to the Arm target. > > Essentially, the change from the displaced stepping improvements made it so > we could still invoke copy_insn_closure_by_addr correctly to return the > pointer to a copy_insn_closure, but it always returned nullptr due to > the order of the statements in displaced_step_buffer::prepare. > > The way it is now, we first write the address of the displaced step buffer > to PC and then save the copy_insn_closure pointer. > > The problem is that writing to PC for the Arm target requires figuring > out if the new PC is thumb mode or not. > > With no copy_insn_closure data, the logic to determine the thumb mode > during displaced stepping doesn't work, and gives random results that > are difficult to track (SIGILL, SIGSEGV etc). > > Fix this by reordering the PC write in displaced_step_buffer::prepare > and, for safety, add an assertion to > displaced_step_buffer::copy_insn_closure_by_addr so GDB stops right > when it sees this invalid situation. If this gets broken again in the > future, it will be easier to spot. > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29272 > --- > gdb/displaced-stepping.c | 15 ++++++++++++--- > 1 file changed, 12 insertions(+), 3 deletions(-) > > diff --git a/gdb/displaced-stepping.c b/gdb/displaced-stepping.c > index eac2c5dab94..19e4df33085 100644 > --- a/gdb/displaced-stepping.c > +++ b/gdb/displaced-stepping.c > @@ -139,15 +139,20 @@ displaced_step_buffers::prepare (thread_info *thread, CORE_ADDR &displaced_pc) > return DISPLACED_STEP_PREPARE_STATUS_CANT; > } > > - /* Resume execution at the copy. */ > - regcache_write_pc (regcache, buffer->addr); > - > /* This marks the buffer as being in use. */ > buffer->current_thread = thread; > > /* Save this, now that we know everything went fine. */ > buffer->copy_insn_closure = std::move (copy_insn_closure); > > + /* Adjust the PC so it points to the displaced step buffer address that will > + be used. This needs to be done after we save the copy_insn_closure, as > + some architectures (Arm, for one) need that information so they can adjust > + other data as needed. In particular, Arm needs to know if the instruction > + being executed in the displaced step buffer is thumb or not. Without that > + information, things will be very wrong in a random way. */ > + regcache_write_pc (regcache, buffer->addr); If the implementation under regcache_write_pc needs to look at the displaced step buffers (like ARM does), it indeed seems like a good idea for current_thread and copy_insn_closure to be set, so the buffer information is complete at that point. However, my worry would be that if regcache_write_pc throws, for some reason, current_thread stays set and the buffer will forever stay marked as busy. Now, when writing the PC fails, things don't look so good for the debug session, but still it would be nice to leave the displaced stepping buffer information in good shape to not make things worse. If all the displaced step buffers (and there's just one on ARM) are busy, threads waiting for a displaced step will be stuck forever. So, perhaps use a try / catch to clear those fields if an exception is thrown (or maybe you can find a cleaner solution). Simon
Hi, On 10/28/22 03:42, Simon Marchi wrote: > > > On 10/26/22 04:41, Luis Machado via Gdb-patches wrote: >> Investigating PR29727, it was mentioned a particular test used to work on > > Typo, 727 <-> 272 Fixed. > >> GDB 10, but it started failing with GDB 11 onwards. I tracked it down to >> some displaced stepping improvements on commit >> 187b041e2514827b9d86190ed2471c4c7a352874. >> >> In particular, one of the corner cases using copy_insn_closure_by_addr got >> silently broken. It is hard to spot because it doesn't have any good tests >> for it, and the situation is quite specific to the Arm target. >> >> Essentially, the change from the displaced stepping improvements made it so >> we could still invoke copy_insn_closure_by_addr correctly to return the >> pointer to a copy_insn_closure, but it always returned nullptr due to >> the order of the statements in displaced_step_buffer::prepare. >> >> The way it is now, we first write the address of the displaced step buffer >> to PC and then save the copy_insn_closure pointer. >> >> The problem is that writing to PC for the Arm target requires figuring >> out if the new PC is thumb mode or not. >> >> With no copy_insn_closure data, the logic to determine the thumb mode >> during displaced stepping doesn't work, and gives random results that >> are difficult to track (SIGILL, SIGSEGV etc). >> >> Fix this by reordering the PC write in displaced_step_buffer::prepare >> and, for safety, add an assertion to >> displaced_step_buffer::copy_insn_closure_by_addr so GDB stops right >> when it sees this invalid situation. If this gets broken again in the >> future, it will be easier to spot. >> >> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29272 >> --- >> gdb/displaced-stepping.c | 15 ++++++++++++--- >> 1 file changed, 12 insertions(+), 3 deletions(-) >> >> diff --git a/gdb/displaced-stepping.c b/gdb/displaced-stepping.c >> index eac2c5dab94..19e4df33085 100644 >> --- a/gdb/displaced-stepping.c >> +++ b/gdb/displaced-stepping.c >> @@ -139,15 +139,20 @@ displaced_step_buffers::prepare (thread_info *thread, CORE_ADDR &displaced_pc) >> return DISPLACED_STEP_PREPARE_STATUS_CANT; >> } >> >> - /* Resume execution at the copy. */ >> - regcache_write_pc (regcache, buffer->addr); >> - >> /* This marks the buffer as being in use. */ >> buffer->current_thread = thread; >> >> /* Save this, now that we know everything went fine. */ >> buffer->copy_insn_closure = std::move (copy_insn_closure); >> >> + /* Adjust the PC so it points to the displaced step buffer address that will >> + be used. This needs to be done after we save the copy_insn_closure, as >> + some architectures (Arm, for one) need that information so they can adjust >> + other data as needed. In particular, Arm needs to know if the instruction >> + being executed in the displaced step buffer is thumb or not. Without that >> + information, things will be very wrong in a random way. */ >> + regcache_write_pc (regcache, buffer->addr); > > If the implementation under regcache_write_pc needs to look at the > displaced step buffers (like ARM does), it indeed seems like a good idea > for current_thread and copy_insn_closure to be set, so the buffer > information is complete at that point. However, my worry would be that > if regcache_write_pc throws, for some reason, current_thread stays set > and the buffer will forever stay marked as busy. Now, when writing the > PC fails, things don't look so good for the debug session, but still it > would be nice to leave the displaced stepping buffer information in good > shape to not make things worse. If all the displaced step buffers (and > there's just one on ARM) are busy, threads waiting for a displaced step > will be stuck forever. > > So, perhaps use a try / catch to clear those fields if an exception is > thrown (or maybe you can find a cleaner solution). Would a scoped restore be cleaner here? > > Simon
On 10/28/22 10:53, Luis Machado wrote: > Hi, > > On 10/28/22 03:42, Simon Marchi wrote: >> >> >> On 10/26/22 04:41, Luis Machado via Gdb-patches wrote: >>> Investigating PR29727, it was mentioned a particular test used to work on >> >> Typo, 727 <-> 272 > > Fixed. > >> >>> GDB 10, but it started failing with GDB 11 onwards. I tracked it down to >>> some displaced stepping improvements on commit >>> 187b041e2514827b9d86190ed2471c4c7a352874. >>> >>> In particular, one of the corner cases using copy_insn_closure_by_addr got >>> silently broken. It is hard to spot because it doesn't have any good tests >>> for it, and the situation is quite specific to the Arm target. >>> >>> Essentially, the change from the displaced stepping improvements made it so >>> we could still invoke copy_insn_closure_by_addr correctly to return the >>> pointer to a copy_insn_closure, but it always returned nullptr due to >>> the order of the statements in displaced_step_buffer::prepare. >>> >>> The way it is now, we first write the address of the displaced step buffer >>> to PC and then save the copy_insn_closure pointer. >>> >>> The problem is that writing to PC for the Arm target requires figuring >>> out if the new PC is thumb mode or not. >>> >>> With no copy_insn_closure data, the logic to determine the thumb mode >>> during displaced stepping doesn't work, and gives random results that >>> are difficult to track (SIGILL, SIGSEGV etc). >>> >>> Fix this by reordering the PC write in displaced_step_buffer::prepare >>> and, for safety, add an assertion to >>> displaced_step_buffer::copy_insn_closure_by_addr so GDB stops right >>> when it sees this invalid situation. If this gets broken again in the >>> future, it will be easier to spot. >>> >>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29272 >>> --- >>> gdb/displaced-stepping.c | 15 ++++++++++++--- >>> 1 file changed, 12 insertions(+), 3 deletions(-) >>> >>> diff --git a/gdb/displaced-stepping.c b/gdb/displaced-stepping.c >>> index eac2c5dab94..19e4df33085 100644 >>> --- a/gdb/displaced-stepping.c >>> +++ b/gdb/displaced-stepping.c >>> @@ -139,15 +139,20 @@ displaced_step_buffers::prepare (thread_info *thread, CORE_ADDR &displaced_pc) >>> return DISPLACED_STEP_PREPARE_STATUS_CANT; >>> } >>> - /* Resume execution at the copy. */ >>> - regcache_write_pc (regcache, buffer->addr); >>> - >>> /* This marks the buffer as being in use. */ >>> buffer->current_thread = thread; >>> /* Save this, now that we know everything went fine. */ >>> buffer->copy_insn_closure = std::move (copy_insn_closure); >>> + /* Adjust the PC so it points to the displaced step buffer address that will >>> + be used. This needs to be done after we save the copy_insn_closure, as >>> + some architectures (Arm, for one) need that information so they can adjust >>> + other data as needed. In particular, Arm needs to know if the instruction >>> + being executed in the displaced step buffer is thumb or not. Without that >>> + information, things will be very wrong in a random way. */ >>> + regcache_write_pc (regcache, buffer->addr); >> >> If the implementation under regcache_write_pc needs to look at the >> displaced step buffers (like ARM does), it indeed seems like a good idea >> for current_thread and copy_insn_closure to be set, so the buffer >> information is complete at that point. However, my worry would be that >> if regcache_write_pc throws, for some reason, current_thread stays set >> and the buffer will forever stay marked as busy. Now, when writing the >> PC fails, things don't look so good for the debug session, but still it >> would be nice to leave the displaced stepping buffer information in good >> shape to not make things worse. If all the displaced step buffers (and >> there's just one on ARM) are busy, threads waiting for a displaced step >> will be stuck forever. >> >> So, perhaps use a try / catch to clear those fields if an exception is >> thrown (or maybe you can find a cleaner solution). > > Would a scoped restore be cleaner here? > Nevermind, that doesn't help us here. >> >> Simon >
diff --git a/gdb/displaced-stepping.c b/gdb/displaced-stepping.c index eac2c5dab94..19e4df33085 100644 --- a/gdb/displaced-stepping.c +++ b/gdb/displaced-stepping.c @@ -139,15 +139,20 @@ displaced_step_buffers::prepare (thread_info *thread, CORE_ADDR &displaced_pc) return DISPLACED_STEP_PREPARE_STATUS_CANT; } - /* Resume execution at the copy. */ - regcache_write_pc (regcache, buffer->addr); - /* This marks the buffer as being in use. */ buffer->current_thread = thread; /* Save this, now that we know everything went fine. */ buffer->copy_insn_closure = std::move (copy_insn_closure); + /* Adjust the PC so it points to the displaced step buffer address that will + be used. This needs to be done after we save the copy_insn_closure, as + some architectures (Arm, for one) need that information so they can adjust + other data as needed. In particular, Arm needs to know if the instruction + being executed in the displaced step buffer is thumb or not. Without that + information, things will be very wrong in a random way. */ + regcache_write_pc (regcache, buffer->addr); + /* Tell infrun not to try preparing a displaced step again for this inferior if all buffers are taken. */ thread->inf->displaced_step_state.unavailable = true; @@ -264,7 +269,11 @@ displaced_step_buffers::copy_insn_closure_by_addr (CORE_ADDR addr) for (const displaced_step_buffer &buffer : m_buffers) { if (addr == buffer.addr) + { + /* The closure information should always be available. */ + gdb_assert (buffer.copy_insn_closure.get () != nullptr); return buffer.copy_insn_closure.get (); + } } return nullptr;