From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR03-AM7-obe.outbound.protection.outlook.com (mail-am7eur03on2076.outbound.protection.outlook.com [40.107.105.76]) by sourceware.org (Postfix) with ESMTPS id 731A43858437 for ; Wed, 5 Oct 2022 08:27:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 731A43858437 ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=iW2bQ56/AZauYixs4C+xGhb4xIMv6K+9DoctLahDTXn3eHfQd3CksjlX7trT1vH+LJXReCnrJZ5d82/bCkXf8imnaqq1pQ2nsPfsJelpVmjqR4Fb8g3vwoDbqYSfGSD2LVMCgY9Oa732VggNJ2Ue7drdrjguHLjo5mmHgZfSfsAHkbex4DY4VQqT5DNgJc2YQXmPgyoJ+CW37vDV1WjEl8GZ+9rXbgAR0WQ02H1pHtuNqVjGUR9ymZz7Yl+EqXtVydBF/0DXM0q4wgFE1uOh/NfOrg7oNBk3+fr1AFfpLNy/yPbsFXRWYlcIc2unzyITx08mfc8TcpQH322uVHdKjw== 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=oDh1KPsQurbaz/EphO7JCMGxIoVf55S7mrDUJP+g/TM=; b=LCtE8uvNoy3Xyye8MhS0T2jzhqWQoJQpF7YSJzJSteOoDQBHYJwsojexe31YAcPRilJDMuZV0swZzS78r52FX3q6Hz25NHWBJgLJkczYBluBS86pfGXZ2cl0dyUk11jpvUOLw/3oCzTL0s/SDDj1RFviMCZ05C8ccD/Wo9bR0fk6R44cIBfvB0rmKbXhEx5UbIOr9Ec5QzBt/N0r9rDof1Wo2kv/8hjeKEIRwJmjVIBTP+DAJY4iT0N4sEq0teJijkKW87Ss0vhE6MMsEIU6iGRfl1PFFvlcWdF40etkYkj263VIEZEl9I8mGNbh7gHjU8ptve5CXhFVbUlKtaKrtw== 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]) Received: from FR0P281CA0053.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:48::17) by PAVPR08MB9676.eurprd08.prod.outlook.com (2603:10a6:102:31f::15) 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:27:00 +0000 Received: from VE1EUR03FT035.eop-EUR03.prod.protection.outlook.com (2603:10a6:d10:48:cafe::97) by FR0P281CA0053.outlook.office365.com (2603:10a6:d10:48::17) 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:27:00 +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 VE1EUR03FT035.mail.protection.outlook.com (10.152.18.110) 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:26:59 +0000 Received: ("Tessian outbound ce981123c49d:v128"); Wed, 05 Oct 2022 08:26:59 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 119a7cc20a8e8400 X-CR-MTA-TID: 64aa7808 Received: from 9a2f6f8f88d5.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 1D60ECF0-534D-4612-9859-046977E3CE97.1; Wed, 05 Oct 2022 08:26:52 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 9a2f6f8f88d5.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 05 Oct 2022 08:26:52 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=It0voRK8usB2xU0d4okE9cTxb8VdAEvB1JDA/xcFwPGrx5Cif5l6zCKT8pJdTnoKG7k3dmOwkf7hR7C7+p0/F6V6t719MmbKPuHcO86qY13pkc4Fx0ZbBlx5jrvwMRXG3NdpA/oxo37pN2PhFONTC87fUEsa6horUt9WWLvo45bbqZIyAb463SICBJRCCTFLX40smwm7+yBD1I+FAdtG0FbTCst/anLCSCfo9dWSDDW6B8TzCij0xBP8VkJh2lF1acrwXiO8ArJI13dN1xMqIUOzVeHFzojHD/CInmxq/Vri9phEGjKLbwCGCnT+BQFZr1pU3P9eRgR8tQgD1I9bDg== 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=oDh1KPsQurbaz/EphO7JCMGxIoVf55S7mrDUJP+g/TM=; b=hC8Y+Q+jXIp0GWhiUMQOmVxeCWfLvO4uz7jvfO8ciLnmwE3mVDTWImNDJERm0MpflAhpkK1HWFJf6MpnqlL+f9C4xsrgGsx22sjp8yMaNOqPH/6TpJ0wkvyLT9QYDQFFWtgxQZt5+W8d30MtHhkSGwRgQgLjovR0O4YMb9PvZL2CEbS8xnB5fhaHos2olkpK9SZjqCs4Dh2nG9wOAAJpLpPv7y9pMCNc2zBX4FpkFynB4ptUWhoXupY2cRlsHtiogNkvZJuJkNBBdtQnbbomRM7Z8XeaDIejHlBKNGg8vszL0KVk3grgqTq/+6Wp2Enuswie4iAvXAnXJa1c9kmosw== 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 Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Received: from VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) by AS4PR08MB7807.eurprd08.prod.outlook.com (2603:10a6:20b:51a::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5676.30; Wed, 5 Oct 2022 08:26:47 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::c5f9:a25b:a5f2:6094]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::c5f9:a25b:a5f2:6094%5]) with mapi id 15.20.5676.032; Wed, 5 Oct 2022 08:26:46 +0000 Message-ID: <3cb2d818-83e8-4e2d-5e1b-9b555d1a2217@arm.com> Date: Wed, 5 Oct 2022 09:26:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH] [Arm] Remove dead FPA code Content-Language: en-US To: John Baldwin , Pedro Alves , gdb-patches@sourceware.org, David Spickett 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> From: Luis Machado In-Reply-To: <1946bc74-8270-23c4-9483-702b9dbc03de@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P265CA0119.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:c::35) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: VI1PR08MB3919:EE_|AS4PR08MB7807:EE_|VE1EUR03FT035:EE_|PAVPR08MB9676:EE_ X-MS-Office365-Filtering-Correlation-Id: a7921e13-4785-414f-de81-08daa6ab5f95 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: s9wEFjXxjZ12eTpUannP/aI47YSIl116MQXis49woqPmfJvQmoUVOskKgYNKDRcEMh74wKfKCJTQIp7rzzlHroCSQAW7gGT/TLYnDowoSz/Nei1iFQkQu2Gk+Rlo0Z0Ggs9P6CYHNw4TcyB9zzSkUP3LYHAMegwqeqK5KI2iCH8/bceQbkoPAY5gdF9wKPGQnjpe4aWhInBdto1G68CA2oNCArKqAt16GZ2IYeKSIOWhBut6/JwVTW85uNc9E/seWXBYgzzv5p1ztpxntKHYihhHAJfkzRLiPhPe12crTnZKVoL9YlIeakb8GlF0bC3Wxd236C5sKPyuYQIHX2lbN4XouytVt43xFg5wzuv3uw3KSoDE/suHEIIDKHVG/fDegJFMzTG3fV8xiM033q1k3mJke7FtgQY8bPCcqKW8+V3HyivFj9sbYLAWGFyWywlRJ2EFaFF6fzG8ttFmnwf8Z1XltLWRLp7WeYhpQns85AiWbwOghAIKB5oEBAfXDkdz5kLTrZE4EDRkcmts14i4I+n6s1JvOouK/uHwYNonz05GG1vsah6GlmBxZwWFgrB9ypxG60mjANtWMgidgaA8HHx5m4KDREy7piTk0B0+9xG5+Eu3nwhUA8r0HBOAZJpHAEXas4RDJ48tO7WxTHLM9qZ6ZvGysHHTu7P/xI+QgwAILUnoS43K533NdE2UlrnYHKpFq6OoSa6TJB86InOHnO+PTQ0gNp5kPKUu99DBhnkSPDvIpxcPUP+PilttsuocePzk8LsHfIP1tStlDac0p6PJLd+tqc6R0suOawjLgWPSpLFmb/iYrDB9uIp1L0yB X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR08MB3919.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(4636009)(346002)(366004)(39860400002)(136003)(376002)(396003)(451199015)(66556008)(8676002)(66946007)(2906002)(66476007)(83380400001)(186003)(41300700001)(36756003)(26005)(6512007)(2616005)(966005)(6486002)(31686004)(478600001)(53546011)(31696002)(86362001)(110136005)(38100700002)(316002)(44832011)(6636002)(6506007)(66899015)(8936002)(5660300002)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR08MB7807 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: VE1EUR03FT035.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 54113fc1-48b1-40fc-f235-08daa6ab5710 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: t3ib+d6RNaLoYmeD0VT5cG7LwvWSwv/0jBR1o8w3kndyMPo6isolKnbG0BZJkapChLGTjENVh4+G9g1S0xydpABJXp/qirot9mKlBqKvthyxsG0Aortql8MJo4EW0tyJf+ja6TVbr60KFYmwAZi5hq0O+FGZUTqwsTIgNRg5WjmpudsWJSipN+oWRkvL9LWEUYLFCZA1/+s9yjFSD2eeCyT5WVRzxxbI7rwQ2LGUp9XHp6sk2ib8TkHJqAMT8C5bnufxCLn4/SX6tcTejsZ39n2hMvEiEEdB4i9RX+SpR3Ikv4f//ul28UKEqZ6oG0s4b3lGsRp0dfJoH3ZrupWaXUK1pSjewx8r6kIHOxoGqa2rlRpTUQyLIwukudKO6vgwVf0FIaPwXICZEyQluS7tu5Xck0eOD6btObCvXZmqC0cjn+b93+zhlZKuFRrN0PqJcoVNKnvRSijMDX005EwUgOh9bzhppdgcbSXQgzKeNdF21ItkLLxxW6CxPlCIk/CadS8Nb/bIak05lc/r0Xf0tV7++n5kT3nHsYi/YFOVsjlTlOHlS/C3296KJ993kWer1QyX+JNxdpvOBB577+/enjcm883rj75q1ydVJFaNLGvUWNkSnKfuMwcHVoc6EH1EHoGxtgJtEqwAXtbRZvQ2412v4FqhCsYMjuAQwTGpq94PN9LeELZW6fnxgzZmRFjs7CpSmIZEBr9J3/VSmkDWPpW1Sop80yeVIf4HPd4VkU1cb21BRddnYihFkCEqdRmullGGGWDqAGEbk59wv6Y2WCeGAd3dbm33u/idRFu+XVXAeM8HioPuKyMl5aM89hiAZK536uN85alsAHVrb2j2NQ== 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)(346002)(136003)(39860400002)(376002)(396003)(451199015)(46966006)(40470700004)(36840700001)(6512007)(26005)(53546011)(6506007)(2616005)(186003)(6486002)(478600001)(966005)(2906002)(44832011)(82310400005)(36756003)(40480700001)(40460700003)(5660300002)(70586007)(70206006)(8676002)(316002)(6636002)(110136005)(8936002)(41300700001)(31686004)(36860700001)(82740400003)(81166007)(356005)(336012)(83380400001)(66899015)(31696002)(86362001)(47076005)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Oct 2022 08:26:59.8129 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a7921e13-4785-414f-de81-08daa6ab5f95 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: VE1EUR03FT035.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR08MB9676 X-Spam-Status: No, score=-11.6 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, FORGED_SPF_HELO, GIT_PATCH_0, KAM_DMARC_NONE, NICE_REPLY_A, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2022 08:27:25 -0000 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 = 13,        /* Contains address of top of stack */ >>>>>>       ARM_LR_REGNUM = 14,        /* address to return to from a function call */ >>>>>>       ARM_PC_REGNUM = 15,        /* Contains program counter */ >>>>>> -  /* F0..F7 are the fp registers for the (obsolete) FPA architecture.  */ >>>>> >>>>> Shouldn't we leave behind a comment explaining why there's a hole between 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 well, 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 when the target >>>>> doesn't send an xml tdesc, so it'd be good to help future readers understand why >>>>> there's a hole. >>>> >>>> That's correct. Though a 32-bit Arm target that doesn't support XML descriptions 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 target descriptions back as unsupported. >>>> >>>> To that effect, I suppose we should add a note to make it more explicit. >>>> >>>> More below. >>> >>> FWIW, the GDB stub in FreeBSD's kernel does not use XML target descriptions >>> for any architectures, but it also only tends to do GPRs and not any floating >>> point.  For 32-bit ARM it does not report any register values higher than >>> 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 see 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 = gdb_cpu_regsz(regnum); > >     if (kdb_thread == curthread) { >         if (regnum < 13) >             return (&kdb_frame->tf_r0 + regnum); >         if (regnum == 13) >             return (&kdb_frame->tf_svc_sp); >         if (regnum == 14) >             return (&kdb_frame->tf_svc_lr); >         if (regnum == 15) >             return (&kdb_frame->tf_pc); >         if (regnum == 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 = 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 = *(register_t *) >                   (kdb_thrctx->pcb_regs.sf_sp + 4 * 4); >               return (&kdb_thrctx->pcb_regs.sf_pc); >           } >     } > >     return (NULL); > } > > The 'kdb_thread == curthread' case is when a thread enters the debugger 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 register > 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 placed >      * in between the PC and CSPR in response to a "g" packet. >      */ >     return (regnum >= 16 && regnum <= 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=1.28&content-type=text/x-cvsweb-markup&only_with_tag=MAIN > > (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/arch/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 for 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 Kernel's side, but I never dealt with the BSD kernels.