From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2060.outbound.protection.outlook.com [40.107.22.60]) by sourceware.org (Postfix) with ESMTPS id 5895B3861916 for ; Fri, 3 Jul 2020 16:06:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5895B3861916 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=Alan.Hayward@arm.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=N8gTO8y4vAcgGDc6ZqHYJdrem/qvYUlkEJ7vwLbZbbI=; b=Y3xFAq5JK4mtnwVB6gB3UfOj2yz07xnfPpnpDAVvSBdQBOE5xKobvI8AWMv90qTG0WyicBi2Zpk9QMUQNIlpq1x1nN1t4EcZ5a2Z2alM+xE7gINwFWQHUDqNqSaL9AKMpIQZI00yZQ4EY+f7miQkYoimUw6vhoy/3keyj4RpwJk= Received: from AM5PR0701CA0018.eurprd07.prod.outlook.com (2603:10a6:203:51::28) by VI1PR08MB2927.eurprd08.prod.outlook.com (2603:10a6:802:21::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.23; Fri, 3 Jul 2020 16:06:55 +0000 Received: from AM5EUR03FT050.eop-EUR03.prod.protection.outlook.com (2603:10a6:203:51:cafe::32) by AM5PR0701CA0018.outlook.office365.com (2603:10a6:203:51::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.8 via Frontend Transport; Fri, 3 Jul 2020 16:06:55 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; sourceware.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; sourceware.org; dmarc=bestguesspass 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; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT050.mail.protection.outlook.com (10.152.17.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.24 via Frontend Transport; Fri, 3 Jul 2020 16:06:55 +0000 Received: ("Tessian outbound 8239f48e56bd:v62"); Fri, 03 Jul 2020 16:06:55 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: d4c453a297d0c5dd X-CR-MTA-TID: 64aa7808 Received: from ec64af99d1d7.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 85F27127-C584-49D8-AFBF-2800D8541D8D.1; Fri, 03 Jul 2020 16:06:49 +0000 Received: from EUR03-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id ec64af99d1d7.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 03 Jul 2020 16:06:49 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Rac4kdsjdUciK18I6yVI73n9q3JXQ0Hkq6n0scwv8rY0AhMpaIircTCg3RyNCT8I1pdSst40zZN89rn4rIWXd8wahejjARejvWxfYWo/krx65n8A/5kVWIvOoDuHG+HKEgvW+dawxrHl32febQEoxDQqdzPayra6YH748ffW9yg/HxeTNNK326MUM32YZHpizMyxQmxx/ljr1n/8qlMr60OqArOXDwEbEi4khFI7bCdKat2oGAPLrdeDZDVi+GxfMYyx8PNwG9HmG/W60alE3lnmsdcfxHjtiypvpaIQHKnO3VBSgcY7fsvS78NU64ti3hwS1FUpfQu6G20SFpEo+A== 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-SenderADCheck; bh=N8gTO8y4vAcgGDc6ZqHYJdrem/qvYUlkEJ7vwLbZbbI=; b=jA6TZ0tvrSztyWLDbghVQAcbdJeTdU6o6QeGTBa3IUDpyBPOnROEN/DuWj49Tfl37g6lNh06pETkXy6Q8ncWipAiXFy0KgfMXSy1lHPTbDjTKvoHtZpHG7/pKegHKKnjayieU/bhPdhKnCt9yockI+4HHfJDpcAucWKNsCmi2I5MgNsKWiLzfWCO0ZgX+U0ECGHD00iX8C7Y7krVFUyXSASBDAFcY1dxsizwosfggMdQtdsuc1CRySF9NaTvCrjR3CQ9jky810XWl1J1EOMFl1Rd5dKlpjNb1cEz+e0PWsPsvKIZaU/2cgMZuCYEWlG3YbiZkIU6ZXIc5VJ3kyw2yQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=N8gTO8y4vAcgGDc6ZqHYJdrem/qvYUlkEJ7vwLbZbbI=; b=Y3xFAq5JK4mtnwVB6gB3UfOj2yz07xnfPpnpDAVvSBdQBOE5xKobvI8AWMv90qTG0WyicBi2Zpk9QMUQNIlpq1x1nN1t4EcZ5a2Z2alM+xE7gINwFWQHUDqNqSaL9AKMpIQZI00yZQ4EY+f7miQkYoimUw6vhoy/3keyj4RpwJk= Received: from AM6PR08MB3957.eurprd08.prod.outlook.com (2603:10a6:20b:a2::14) by AM5PR0801MB1779.eurprd08.prod.outlook.com (2603:10a6:203:2f::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.23; Fri, 3 Jul 2020 16:06:48 +0000 Received: from AM6PR08MB3957.eurprd08.prod.outlook.com ([fe80::49d4:5842:e85c:2258]) by AM6PR08MB3957.eurprd08.prod.outlook.com ([fe80::49d4:5842:e85c:2258%6]) with mapi id 15.20.3153.028; Fri, 3 Jul 2020 16:06:48 +0000 From: Alan Hayward To: Luis Machado CC: Matthew Malcomson , gdb-patches , nd Subject: Re: [Patch] GDB: aarch64: Add ability to step over a BR/BLR instruction Thread-Topic: [Patch] GDB: aarch64: Add ability to step over a BR/BLR instruction Thread-Index: AQHWUUqqP0MGDT2LB0Gb53DxR2oIqaj1/NiAgAAHqQA= Date: Fri, 3 Jul 2020 16:06:48 +0000 Message-ID: <9EACDC38-BB8D-4804-AD19-057E3309819A@arm.com> References: <9226b8ae-aaea-65c3-3e86-f607b11fd375@linaro.org> In-Reply-To: <9226b8ae-aaea-65c3-3e86-f607b11fd375@linaro.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) Authentication-Results-Original: linaro.org; dkim=none (message not signed) header.d=none;linaro.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.23.123.38] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: f402a773-191c-433b-b79f-08d81f6b1b5a x-ms-traffictypediagnostic: AM5PR0801MB1779:|VI1PR08MB2927: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:9508; x-forefront-prvs: 045315E1EE X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 29Wfc1Mmn/xhDIDTnEkG6xgaEy4ORh6ZBSZ/tXKRGkyh6uVJjaJiJLmNkWtC/5+YLkDVydjxUY//GU9HkEHP48TID+vrkhdEs785psgyf0MAbv4Vz9CuEkPntkXTnyME1HLmel2DzY9lpZi/IjrvuRP18DpJawlwnXgmvAgtF08Y8heTGXaUAuoov4HpkGx5qA8C/0X8/s2M+9GKdOn4F00t35hi1GZlYxF13T9xWGM4WQFNdsxnnAQkPK8O9uZMwWoLorKHY3Q/Bb02h0bzLz6iKGd2lFHGoC3Hwry9fXBh362XA60k6FbzeIbFEY0YUuhn6IoqMc6FAQAtSSTHQw== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB3957.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(376002)(396003)(366004)(346002)(136003)(66946007)(8676002)(316002)(71200400001)(36756003)(6916009)(8936002)(83380400001)(6512007)(86362001)(2616005)(26005)(2906002)(186003)(4326008)(54906003)(6486002)(478600001)(64756008)(91956017)(66476007)(66446008)(76116006)(66556008)(33656002)(53546011)(6506007)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: yvAl8dE1oBKG+WBV/nLRCUB5J4wTmd8hG96oDzbSOIIDX7UIqMcgvPSnj87RJJXeL5U6KnMMOseTM2wYM4l8v9UOmsIGZa+vpYIHsatmBQHLJ8BouChJ6l6RyYWtHWpYBMvMwEyGDRi4IV4eTxEHHV8GXe0DlrZ7becFjg7mwuykx0B6+weZA8oDzb0/tlmNaze7mC6iTAjLxJ+sVawuKcfhVR8D6vq/nrKC8B+R0GKCh04XM3D6HHilXWhE1oyy2cfABElUF8HEOIGdX/xeqG5HDozfYLmLAIMR8Plf5FisH/CT/jZ8qNvAn6tQQaXU3TSM4A4qjG8n0tk42/UXWukMiok1lZ+9InKzw/fMx+8kKXoOAAQ1PdoHz3OdOTSeEqTwz6f5Zq8IsDCpUSOQzFO9BtX4FfVXR6NexCKjmIG9wGFxx6gpJZonyFbO86uOcV1xZ4i6m/CSj5k6gfBjax8FmqSFKRklDKfHiC3EPUY= Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0801MB1779 Original-Authentication-Results: linaro.org; dkim=none (message not signed) header.d=none;linaro.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT050.eop-EUR03.prod.protection.outlook.com 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; SFTY:; SFS:(4636009)(136003)(376002)(346002)(39860400002)(396003)(46966005)(316002)(33656002)(47076004)(26005)(36906005)(82740400003)(336012)(36756003)(6862004)(186003)(2906002)(6512007)(2616005)(5660300002)(70206006)(70586007)(478600001)(82310400002)(83380400001)(81166007)(8676002)(8936002)(54906003)(356005)(6486002)(86362001)(4326008)(6506007)(53546011); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: a62758c9-8647-4db9-994e-08d81f6b1719 X-Forefront-PRVS: 045315E1EE X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: tNmtRPexL1C8EF39YGyLGKu1oZ9Rx2gGoIxvzo0Au6OYA/neoA3LXBItODP8khaQ5kt+bN69wDdqfAPAqF1BMrcd7oo6pkhAkslAS+JZYK9P9rjM3G64FVwDYZynwJiML0HFEVx5n0GSlW7E76XqfxrpmSMTTwejJTi3Olbo347xVCjTZoBTfgAB2PTnEKOP1D/y/oh2DCFBgXY0GbT6yGEjGioVQRyY4aYr40I6OQtoc9rIJ2N092Deh5tgO5Nl/TItm5auCVGzuBBfof5iL7wt84/uP7SbIKektMHQqkvtwYCgLPebFWU4+CYDIXh2ZQheEjodRnktePUCACSw/ffN3mc0N+02C2cO4cgV7B9niUZWTD1qMvwB9juC6Ioev8z1vdyCnFKFf117KGy6Ug== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jul 2020 16:06:55.3227 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f402a773-191c-433b-b79f-08d81f6b1b5a 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: AM5EUR03FT050.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB2927 X-Spam-Status: No, score=-15.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 16:07:00 -0000 > On 3 Jul 2020, at 16:36, Luis Machado wrote: >=20 > cc-ing Alan. >=20 > On 7/3/20 11:55 AM, Matthew Malcomson wrote: >> Enable displaced stepping over a BR/BLR instruction >> Displaced stepping over an instruction executes a instruction in a >> scratch area and then manually fixes up the PC address to leave >> execution where it would have been if the instruction were in its >> original location. >> The BR instruction does not need modification in order to run correctly >> at a different address, but the displaced step fixup method should not >> manually adjust the PC since the BR instruction sets that value already. >> The BLR instruction should also avoid such a fixup, but must also have >> the link register modified to point to just after the original code >> location rather than back to the scratch location. >=20 > Nice catch. >=20 >> This patch adds the above functionality. >> We add this functionality by modifying aarch64_displaced_step_others >> rather than by adding a new visitor method to aarch64_insn_visitor. >> We choose this since it seems that visitor approach is designed >> specifically for PC relative instructions (which must always be modified >> when executed in a different location). >> It seems that the BR and BLR instructions are more like the RET >> instruction which is already handled specially in >> aarch64_displaced_step_others. >> This also means the gdbserver code to relocate an instruction when >> creating a fast tracepoint does not need to be modified, since nothing >> special is needed for the BR and BLR instructions there. >> Manually tested on AArch64 (it doesn't look like there are tests for >> displaced stepping on the other instructions that are manually handled, >> so I figured adding a testcase for BR and BLR would be out of place). >=20 > Not out of place, but those just did not get added. A test that exercises= displaced stepping over those two instructions would be a good addition. T= hat or some unit testing code to make sure the function handled the instruc= tion in the expected way. +1. Was going to write a very similar comment. A test for all the cases wou= ld be great. >=20 >> ------##### >> Observed (mis)behaviour before was that displaced stepping over a BR or >> BLR instruction would not execute the function they called. Most easily >> seen by putting a breakpoint with a condition on such an instruction and >> a print statement in the functions they called. >> When run with the breakpoint enabled the function is not called and >> "numargs called" is not printed. >> When run with the breakpoint disabled the function is called and the >> message is printed. >> --- GDB Session >> hw-a20-10:gcc-source [15:57:14] % gdb ../using-blr >> Reading symbols from ../using-blr...done. >> (gdb) disassemble blr_call_value >> Dump of assembler code for function blr_call_value: >> ... >> 0x0000000000400560 <+28>: blr x2 >> ... >> 0x00000000004005b8 <+116>: ret >> End of assembler dump. >> (gdb) break *0x0000000000400560 >> Breakpoint 1 at 0x400560: file ../using-blr.c, line 22. >> (gdb) condition 1 10 =3D=3D 0 >> (gdb) run >> Starting program: /home/matmal01/using-blr >> [Inferior 1 (process 33279) exited with code 012] >> (gdb) disable 1 >> (gdb) run >> Starting program: /home/matmal01/using-blr >> numargs called >> [Inferior 1 (process 33289) exited with code 012] >> (gdb) >> Test program: >> ---- using-blr ---- >> \#include >> typedef int (foo) (int, int); >> typedef void (bar) (int, int); >> struct sls_testclass { >> foo *x; >> bar *y; >> int left; >> int right; >> }; >> __attribute__ ((noinline)) >> int blr_call_value (struct sls_testclass x) >> { >> int retval =3D x.x(x.left, x.right); >> if (retval % 10) >> return 100; >> return 9; >> } >> __attribute__ ((noinline)) >> int blr_call (struct sls_testclass x) >> { >> x.y(x.left, x.right); >> if (x.left % 10) >> return 100; >> return 9; >> } >> int >> numargs (__attribute__ ((unused)) int left, __attribute__ ((unused)) int= right) >> { >> printf("numargs called\n"); >> return 10; >> } >> void >> altfunc (__attribute__ ((unused)) int left, __attribute__ ((unused)) int= right) >> { >> printf("altfunc called\n"); >> } >> int main(int argc, char **argv) >> { >> struct sls_testclass x =3D { .x =3D numargs, .y =3D altfunc, .left =3D= 1, .right =3D 2 }; >> if (argc > 2) >> { >> blr_call (x); >> } >> else >> blr_call_value (x); >> return 10; >> } >> ------ >> gdb/ChangeLog: >> 2020-07-03 Matthew Malcomson >> * aarch64-tdep.c (aarch64_displaced_step_others): Account for >> BR and BLR instructions. >> * arch/aarch64-insn.h (enum aarch64_opcodes): Add BR instruction. >> ############### Attachment also inlined for ease of reply #######= ######## >> diff --git a/gdb/aarch64-tdep.c b/gdb/aarch64-tdep.c >> index 5e7d0d0b8682af04ce4f01fd999d26c9eb459932..640a3e302f8e2b5fac3575e2= f37212d40441d318 100644 >> --- a/gdb/aarch64-tdep.c >> +++ b/gdb/aarch64-tdep.c >> @@ -2974,15 +2974,22 @@ aarch64_displaced_step_others (const uint32_t in= sn, >> struct aarch64_displaced_step_data *dsd >> =3D (struct aarch64_displaced_step_data *) data; >> - aarch64_emit_insn (dsd->insn_buf, insn); >> - dsd->insn_count =3D 1; >> - >> - if ((insn & 0xfffffc1f) =3D=3D 0xd65f0000) Maybe the 0xfffffc1f mask belongs in aarch64-insn.h >> + uint32_t masked_insn =3D (insn & 0xfffffc1f); >> + if (masked_insn =3D=3D BLR) >> { >> - /* RET */ >> - dsd->dsc->pc_adjust =3D 0; >> + /* Emit a BR to the same register and then update LR to the origi= nal >> + address (similar to aarch64_displaced_step_b). */ >> + aarch64_emit_insn (dsd->insn_buf, insn & 0xffdfffff); >> + regcache_cooked_write_unsigned (dsd->regs, AARCH64_LR_REGNUM, >> + data->insn_addr + 4); >> } >> else >> + aarch64_emit_insn (dsd->insn_buf, insn); >> + dsd->insn_count =3D 1; >> + >> + if (masked_insn =3D=3D RET || masked_insn =3D=3D BR || masked_insn = =3D=3D BLR) >> + dsd->dsc->pc_adjust =3D 0; >> + else >> dsd->dsc->pc_adjust =3D 4; >> } >> diff --git a/gdb/arch/aarch64-insn.h b/gdb/arch/aarch64-insn.h >> index 6a63ce9c2005acd6fe018a12c640f1be01751d6b..6b8721139f8446d82aecac24= 3501d31137c885a5 100644 >> --- a/gdb/arch/aarch64-insn.h >> +++ b/gdb/arch/aarch64-insn.h >> @@ -40,7 +40,9 @@ enum aarch64_opcodes >> CBNZ =3D 0x21000000 | B, >> TBZ =3D 0x36000000 | B, >> TBNZ =3D 0x37000000 | B, >> + /* BR 1101 0110 0001 1111 0000 00rr rrr0 0000 */ >> /* BLR 1101 0110 0011 1111 0000 00rr rrr0 0000 */ >> + BR =3D 0xd61f0000, Not for this patch - but I wonder if this enum could be deleted and instead= use code from ../opcodes/aarch64-tbl.h Random hex values make me nervous, and opcodes/ is already used for the dis= assembler. >> BLR =3D 0xd63f0000, >> /* RET 1101 0110 0101 1111 0000 00rr rrr0 0000 */ >> RET =3D 0xd65f0000, > The patch looks good to me.