From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2079.outbound.protection.outlook.com [40.107.22.79]) by sourceware.org (Postfix) with ESMTPS id 7E28F3857C70 for ; Wed, 5 Oct 2022 08:36:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7E28F3857C70 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=KzUlwKZ3kH5iXql3udTYqIFF0HscsrzbxEvRSJqubd9Y49GD2/T9XZlm13XdNH5n5w/dlKWXAat9sBDnwOPhv8AuXr30C5hV3vL+Lrakf2t8yl7UaVDQ3OCp5WXy/Qz1IQHQmOEuXXAnsysHskbS1+GM83lyGILcwfFtAHYg3KlGwfAlts/P0MRlduajWM2IcXsMCe/NGKYyCgL+dkc1lwslgCyzHn8gdXk1gQZpGGwucudY0KFOQyPnxtZxowaNgSLZGCp66KBfrAnOMRg0bdGHtqK8UJzFKNlURkjbfVHVNt1MOg6C4i81NwGVnbgz04RGQItp5hFBYPT5iYR0fQ== 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=NAnDwuB8+eteYoC+CXP1O0EUip6yMOkdNNFxdaQGRZE=; b=bzhy67srDd1UnayKNWViPPUC32lRBp9JGManYfY6CCIhisgMoHO6lRwaiery1eheJeMCzbzzghAo2yF9LwgT4I5AWvzaAT1HQTmw6uj6ekjpKMjsk9bGeQGW9evkovQUcpVawgbVoPRpKwyr1rPpkKlGDYncqddwxJ6gIC57b3qHTqXdKK6l2lj4wSWstBZj40KcNkCxDmzUp2CVcGnzdOguj6D0EivEnNzYWdyYFllsPNhMs9AoLTSJPZY1apjDhkCqK/LTOkSzgwbWWtyI3yRq6wmK3CFq/0T1lZzBGBFalRif0x97ejM81uhbOVY8mEY54CE+0tfptZVecOGXlQ== 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] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=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=NAnDwuB8+eteYoC+CXP1O0EUip6yMOkdNNFxdaQGRZE=; b=jYaYYF8jb/mljYrN+1onKztKH06Z0dGz73n6XTVCjvkte0k2mYVhPrPaGy1yubZnDXOi+YlX94uWfVYlNFOhEdbSNA2DjwiiXJ/GUmMkrk/A2RxA9KPGOaOjz8JGbob9m5EsVqOKaoC1iy5EHl6Eu5bXvNe5uP8VrSojwlU7BIs= Received: from DB9PR05CA0001.eurprd05.prod.outlook.com (2603:10a6:10:1da::6) by PAVPR08MB9699.eurprd08.prod.outlook.com (2603:10a6:102:31e::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5676.24; Wed, 5 Oct 2022 08:36:25 +0000 Received: from DBAEUR03FT022.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:1da:cafe::90) by DB9PR05CA0001.outlook.office365.com (2603:10a6:10:1da::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5676.32 via Frontend Transport; Wed, 5 Oct 2022 08:36:25 +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 DBAEUR03FT022.mail.protection.outlook.com (100.127.142.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5709.10 via Frontend Transport; Wed, 5 Oct 2022 08:36:25 +0000 Received: ("Tessian outbound 7e4a920b87c0:v128"); Wed, 05 Oct 2022 08:36:25 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 22723bc807705378 X-CR-MTA-TID: 64aa7808 Received: from 15089ae9a9bf.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id C93740B8-6DE3-488C-9214-9E88404C6A5E.1; Wed, 05 Oct 2022 08:36:18 +0000 Received: from EUR03-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 15089ae9a9bf.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 05 Oct 2022 08:36:18 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QlA2V7q7w5/kXQTEH2iPGJtQqnjGfHBz1VvZKnhqWKi7hUgdTveZ4GkoHv9jDIFR8tmBjrjRSIRbC2n/4EduvuVeQDQJDJrz9CH8bMQkweaS+3sw0/PAxlJv8vFxZg0ZgxozNWY2g5jv58RDdAZ0rXx9nY5+zLu7aN8wXC/zixtkM8ga0I19kDO6Jr7X4FRVfF6T+M6ypVcp3mwuIQkiMKGBvr4fNRX93rj9fYIj3LKTRRTJDMPUFhSdFjeSYq7SdMin3c8CQlM+tEq/YBhJ0PtOCNCBvxIhg94t3x2IATBpYLU3L69VzA2oC+FBV9ytE45uyapWRIbgg6hj+yW0nQ== 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=NAnDwuB8+eteYoC+CXP1O0EUip6yMOkdNNFxdaQGRZE=; b=XZG4nDzSqzi7heV2NbyrRf2/zGaQXqF3ZjR7gXUg7nhr0Nl96GbejMU0y/RYPXOR1WxRC8erUt45lzHA+fHw4xkbsIOOckCQPZMYTfRgCcKUFv5ZAXbLfNYym8K9TWQvYnTbBQtrN+aUQmRFUwuhg2dEN8EMw7TpWxX542xpfx/RglqIFRacFzHLgJmp7hl8GbLe4/VoEBTP6+ulpRWSNMZmhOxZFejh3cdLOHE/nmglj2q/7bFBvoLQnD48VOn81MMEoNellDNJlLyxCyauuIqiab7OqK62t2eUWgSNvPjVSYXoqGA4OWHfzUErLSntv2r4H7WNVRyF22K/i7IYmw== 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=NAnDwuB8+eteYoC+CXP1O0EUip6yMOkdNNFxdaQGRZE=; b=jYaYYF8jb/mljYrN+1onKztKH06Z0dGz73n6XTVCjvkte0k2mYVhPrPaGy1yubZnDXOi+YlX94uWfVYlNFOhEdbSNA2DjwiiXJ/GUmMkrk/A2RxA9KPGOaOjz8JGbob9m5EsVqOKaoC1iy5EHl6Eu5bXvNe5uP8VrSojwlU7BIs= Received: from AM7PR08MB5511.eurprd08.prod.outlook.com (2603:10a6:20b:10d::12) by GV2PR08MB7929.eurprd08.prod.outlook.com (2603:10a6:150:ac::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5676.31; Wed, 5 Oct 2022 08:36:14 +0000 Received: from AM7PR08MB5511.eurprd08.prod.outlook.com ([fe80::bc32:49c9:a142:333d]) by AM7PR08MB5511.eurprd08.prod.outlook.com ([fe80::bc32:49c9:a142:333d%5]) with mapi id 15.20.5676.032; Wed, 5 Oct 2022 08:36:14 +0000 From: David Spickett To: Luis Machado , John Baldwin , Pedro Alves , "gdb-patches@sourceware.org" Subject: Re: [PATCH] [Arm] Remove dead FPA code Thread-Topic: [PATCH] [Arm] Remove dead FPA code Thread-Index: AQHY2BjQlliuRM7lWEyZgAmoYoZXFK3+wnCAgAC1xQCAAABlog== Date: Wed, 5 Oct 2022 08:36:14 +0000 Message-ID: References: <20220920123012.189293-1-luis.machado@arm.com> <73479562-ab47-dfbf-aadc-7a2203c0f0e4@FreeBSD.org> <56653c70-593a-4b8d-ddf7-52f7dd0608f7@arm.com> <1946bc74-8270-23c4-9483-702b9dbc03de@FreeBSD.org> <3cb2d818-83e8-4e2d-5e1b-9b555d1a2217@arm.com> In-Reply-To: <3cb2d818-83e8-4e2d-5e1b-9b555d1a2217@arm.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: AM7PR08MB5511:EE_|GV2PR08MB7929:EE_|DBAEUR03FT022:EE_|PAVPR08MB9699:EE_ X-MS-Office365-Filtering-Correlation-Id: ac542f3e-02f5-43f8-70f9-08daa6acb091 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: s0bC0vqV4+834n/exAWJSVet+6tZdmsFJoSHRPfYS7T1N9L4H/YsGZGb2XIif1PrBxDVggozBhThLDoF+sogApvcws0OjyiWeaTEQVgXjDEkHw+8E0iGv85Ff/g0YndrAl8pw/CcQogcqGdVGY6vPqqozn/kwl5CNp71TxRfWXvjYOwX7iltaJcyo1YtMoJnD6e4Xtk1CPZicHrp9gBfcEcV1o1DOBbcPOJTqVOdBV+/+XNn9U5H8HP5pSzrFWB13bao4OAdpO3uuw4mimNY1twXaXeX1i5mV2AGlIaXeekRm5JsElI0ean+lIGHUTEmAogw8pVVGpSxuTbMtbk6iHlduPPXl0QX1CrQlSSHZX6cI9pjxHBaciIxm+RR16XgnL1WC3BX4qvuJKKLOkbR4D6Tk3yFakv7ku958AKM10eqSE4uNx5hQ9WQNYO9jOekAcvAdcpYW89tM5pDGDZPRgqbe87pm0XlvhkbDcdIhIg35uRwKGQU7ar2/rML22yxxJ4Kl829nq+fs7/p0Lo0W3NFTqWzdJgu8xcaWNvF8g6av+pEUKfu/B0mdat8WvWm4xs/vmeoIbAVE3egceEcp9QW+9u1BZBjGym4BLtT2M+jMJEVoo6RfBZdshDJmbYglz6sGv3iekBZHhlYMteLKSndaYXaEbIRLKASHlxlEVZauIEwDG3DYK7jDpyqpDxWczh+kXGCKbDjZ9ILdif3WWn21YPGg7+CbkdCxkTpog11kFRzlEu0YGVDHp5eiqlNOS5y/rxw63ljAiMb2EUUmS4JkwIBCn2SUv+9VyVSp0w= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM7PR08MB5511.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230022)(4636009)(396003)(376002)(366004)(346002)(136003)(39860400002)(451199015)(186003)(83380400001)(166002)(38070700005)(55016003)(122000001)(38100700002)(76116006)(66946007)(66476007)(66556008)(8676002)(64756008)(66446008)(91956017)(316002)(2906002)(41300700001)(52536014)(5660300002)(8936002)(110136005)(53546011)(7696005)(6506007)(9686003)(26005)(966005)(71200400001)(478600001)(33656002)(19627405001)(86362001)(66899015);DIR:OUT;SFP:1101; Content-Type: multipart/alternative; boundary="_000_AM7PR08MB5511AD38382E5C19D547C22E9C5D9AM7PR08MB5511eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR08MB7929 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DBAEUR03FT022.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: fb0c4fcd-41e7-468b-4695-08daa6acaa22 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: CJ6waRVqhhXJqYgN1FH/f5I/LZSUbpyj5SesRqCLAKYwIJ7uw1HHGcKjhvR34j2lULi9n6acN+OvYxex8Z2yX9qOqAI/cKjA8eZxphHyuYdEYFVKKW1VwJVGOpfI81ImzACfKE++Rk/j5wENGypTg8uPsgqam0paca4jw6ydedZaEXRs4vXs3MOKyXqRpcfGedttGm6X9ou81/rmamXNSf2RjdsUi/vtvM7wsOCXJjuA5EbAPwX+LAhP6i8qdHM20ueE4roA7YvKsAlByjKKCWB+W4VPCHjYPLOkIx7shyOU8UCxbEFdk+ZFPyazvBDI1tROh4eRhFvIsK5Nc2TbhCw85gY+VB9tn3c9zssD5MPtiubSKEjk4oLLSTqxfAiNlwKX9UTSVCypaXYWIcJ8tTFsm0vahEDNRTLCbvEXg1eUJj2T2cq/DPiD2HdvoKRdLkuJwiZ3N9Y0VaDbnRAr/0NdY+a6iHsjtKGrD7tGssEXZRyfjEB7YXG8GMId/z76HeOE1jOCtuJR7xNMDJ6NJ9zi0qgKkcZDcolHgYCC/7JV83vXpM99euHGikdbHzbz2e4gYIAXULv22tXLpj4jM8AMPUOUfffWtR/56XvjHzXBQzAukyaaIAmwc5msFD+uISV+CLNbQZClbLNwt4u8opbnQaRllTIEmaYHv5qgcDNInYJsT/Y5lfQRMPfHKormqxFW6CIq3CImRiYZyRMqEenkLxkSgdpTuFq9IItV1eeiOPbRDNOVC29e7m25EkXhSPuxFurdRpUe5w1UmI/cbRWzvhpEztDES41Y6rsi29Q= 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)(39860400002)(376002)(346002)(396003)(136003)(451199015)(40470700004)(36840700001)(46966006)(186003)(81166007)(336012)(47076005)(166002)(83380400001)(356005)(36860700001)(82740400003)(30864003)(2906002)(8936002)(52536014)(5660300002)(41300700001)(82310400005)(40480700001)(55016003)(40460700003)(478600001)(966005)(6506007)(7696005)(8676002)(70586007)(26005)(9686003)(70206006)(316002)(53546011)(33656002)(110136005)(19627405001)(66899015)(86362001);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Oct 2022 08:36:25.3253 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ac542f3e-02f5-43f8-70f9-08daa6acb091 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: DBAEUR03FT022.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR08MB9699 X-Spam-Status: No, score=-13.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,FORGED_SPF_HELO,GIT_PATCH_0,HTML_MESSAGE,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 List-Id: Message-ID: <20221005083614.egav-x6dg2-QeRF_dwzAx-_YLyjernuhR1bewwGU8HM@z> --_000_AM7PR08MB5511AD38382E5C19D547C22E9C5D9AM7PR08MB5511eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > David, does LLDB actively maintain register descriptions for 32-bit Arm? LLDB has 4 mechanisms for describing registers: * XML register info (lldb-server doesn't generate this itself for 32-bi= t Arm but lldb will read it if given) * qRegisterInfo packet, which tells you the offset of a given register = index in the G packet amongst other things (this is an lldb specific packet= iirc) * A script like the one you linked to * A fallback set of register defs hardcoded. This only has registers fo= r AArch64, x86 and x86_64 and only includes general purpose registers. As for FPA support all we have is the DWARF numbers. Pretty safe to say no = support. ________________________________ From: Luis Machado Sent: 05 October 2022 09:26 To: John Baldwin ; Pedro Alves ; gdb-pat= ches@sourceware.org ; David Spickett Subject: Re: [PATCH] [Arm] Remove dead FPA code On 10/4/22 22:36, John Baldwin wrote: > On 10/4/22 10:43 AM, Luis Machado wrote: >> On 10/4/22 18:08, John Baldwin wrote: >>> On 10/4/22 1:43 AM, Luis Machado via Gdb-patches wrote: >>>> On 10/3/22 20:16, Pedro Alves wrote: >>>>> On 2022-09-20 1:30 p.m., Luis Machado via Gdb-patches wrote: >>>>> >>>>>> diff --git a/gdb/arch/arm.h b/gdb/arch/arm.h >>>>>> index 36757493406..74a6ba93bc7 100644 >>>>>> --- a/gdb/arch/arm.h >>>>>> +++ b/gdb/arch/arm.h >>>>>> @@ -44,11 +44,6 @@ enum gdb_regnum { >>>>>> ARM_SP_REGNUM =3D 13, /* Contains address of top of sta= ck */ >>>>>> ARM_LR_REGNUM =3D 14, /* address to return to from a fu= nction call */ >>>>>> ARM_PC_REGNUM =3D 15, /* Contains program counter */ >>>>>> - /* F0..F7 are the fp registers for the (obsolete) FPA architectur= e. */ >>>>> >>>>> Shouldn't we leave behind a comment explaining why there's a hole bet= ween 15 and 25? >>>> >>>> I pondered about this a bit more, and I think we should close the gap = and bring CPSR down to >>>> 16, its "natural" position. It is what linux uses for user_regs as wel= l, in gdb/arch/arm-linux.h: >>>> >>>> /* The index to access CSPR in user_regs defined in GLIBC. */ >>>> #define ARM_CPSR_GREGNUM 16 >>>> >>>>> >>>>> IIRC the numbers can't be changed since we need to handle the case wh= en the target >>>>> doesn't send an xml tdesc, so it'd be good to help future readers und= erstand why >>>>> there's a hole. >>>> >>>> That's correct. Though a 32-bit Arm target that doesn't support XML de= scriptions these days is not very >>>> common. I haven't seen one in a while. >>>> >>>> I'm willing to declare old 32-bit Arm targets that don't send XML targ= et descriptions back as unsupported. >>>> >>>> To that effect, I suppose we should add a note to make it more explici= t. >>>> >>>> More below. >>> >>> FWIW, the GDB stub in FreeBSD's kernel does not use XML target descript= ions >>> for any architectures, but it also only tends to do GPRs and not any fl= oating >>> point. For 32-bit ARM it does not report any register values higher th= an >>> number 15 (PC), so it would not be affected by changing this. >> >> Does it care about CPSR and/or XPSR? Could you please give it a try to s= ee if the defaults would suit it just fine? > > Hmm, I misread and it does care about CPSR for the current thread. The > relevant code is here (From https://cgit.freebsd.org/src/tree/sys/arm/arm= /gdb_machdep.c): > > void * > gdb_cpu_getreg(int regnum, size_t *regsz) > { > > *regsz =3D gdb_cpu_regsz(regnum); > > if (kdb_thread =3D=3D curthread) { > if (regnum < 13) > return (&kdb_frame->tf_r0 + regnum); > if (regnum =3D=3D 13) > return (&kdb_frame->tf_svc_sp); > if (regnum =3D=3D 14) > return (&kdb_frame->tf_svc_lr); > if (regnum =3D=3D 15) > return (&kdb_frame->tf_pc); > if (regnum =3D=3D 25) > return (&kdb_frame->tf_spsr); > } > > switch (regnum) { > case 4: return (&kdb_thrctx->pcb_regs.sf_r4); > case 5: return (&kdb_thrctx->pcb_regs.sf_r5); > case 6: return (&kdb_thrctx->pcb_regs.sf_r6); > case 7: return (&kdb_thrctx->pcb_regs.sf_r7); > case 8: return (&kdb_thrctx->pcb_regs.sf_r8); > case 9: return (&kdb_thrctx->pcb_regs.sf_r9); > case 10: return (&kdb_thrctx->pcb_regs.sf_r10); > case 11: return (&kdb_thrctx->pcb_regs.sf_r11); > case 12: return (&kdb_thrctx->pcb_regs.sf_r12); > case 13: stacktest =3D kdb_thrctx->pcb_regs.sf_sp + 5 * 4; > return (&stacktest); > case 15: > /* > * On context switch, the PC is not put in the PCB, but > * we can retrieve it from the stack. > */ > if (kdb_thrctx->pcb_regs.sf_sp > KERNBASE) { > kdb_thrctx->pcb_regs.sf_pc =3D *(register_t *) > (kdb_thrctx->pcb_regs.sf_sp + 4 * 4); > return (&kdb_thrctx->pcb_regs.sf_pc); > } > } > > return (NULL); > } > > The 'kdb_thread =3D=3D curthread' case is when a thread enters the debugg= er due > to a crash or breakpoint, etc. We do return CPSR for that thread, but we= do > not return it for other threads. It looks like we do also know the FPA r= egister > size so that we return enough "xx" bytes in the 'g' reply to mark the FP > registers as unavailable so that we can return the value of CPSR in the '= g' > reply. > > From https://cgit.freebsd.org/src/tree/sys/arm/include/gdb_machdep.h: > > #define GDB_NREGS 26 > #define GDB_REG_SP 13 > #define GDB_REG_LR 14 > #define GDB_REG_PC 15 > > static __inline size_t > gdb_cpu_regsz(int regnum) > { > /* > * GDB expects the FPA registers f0-f7, each 96 bits wide, to be pla= ced > * in between the PC and CSPR in response to a "g" packet. > */ > return (regnum >=3D 16 && regnum <=3D 23 ? 12 : sizeof(int)); > } > > NetBSD's kernel seems to have similar knowledge: > > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/arm/include/db_machdep.h= ?rev=3D1.28&content-type=3Dtext/x-cvsweb-markup&only_with_tag=3DMAIN > > (The kgdb bits near the bottom) > > Linux's kernel also seems to maybe hardcode this knowledge as well: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/a= rch/arm/kernel/kgdb.c#n21 > Yeah, that's what I was worried about. Register discoveries without XML are= not great, and more recently debugging stubs have been exposing more system registers. Having to consider FPA (which was *removed*= 10 years ago from GCC, but fell in disuse before then) is not acceptable at this point. If those debugging stubs want to skip XML, I think it would be reasonable f= or them to at least update the expected 'g' packet to contain just the basic registers, with CPSR as 16. That might need some coordination. I can coordinate this from the Linux Ker= nel's side, but I never dealt with the BSD kernels. --_000_AM7PR08MB5511AD38382E5C19D547C22E9C5D9AM7PR08MB5511eurp_--