From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR03-DBA-obe.outbound.protection.outlook.com (mail-dbaeur03on2054.outbound.protection.outlook.com [40.107.104.54]) by sourceware.org (Postfix) with ESMTPS id CC11D385483D for ; Tue, 12 Sep 2023 15:10:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CC11D385483D Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=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=7gJJ15HVTP5nzIrGMX156qUB4RA/sVrV3lzww+7mWqo=; b=kaAeBrR4SKH6jqHsvzshJFC0pJSdYBI0GNcCgfv2sViGBh4toX8cRoZLCEGFvcj5oc9dZyAipeDzH+NSHF9IS1wO5gLg19vc/0dYub62IELxNAhwEFxvZQnNn/eRvtG8vF49NMC942Zh/X01SeFa+Iqtn7vEz12EGrsRoKvFemU= Received: from DU2P251CA0016.EURP251.PROD.OUTLOOK.COM (2603:10a6:10:230::18) by PA4PR08MB5918.eurprd08.prod.outlook.com (2603:10a6:102:e7::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6768.35; Tue, 12 Sep 2023 15:10:55 +0000 Received: from DBAEUR03FT011.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:230:cafe::22) by DU2P251CA0016.outlook.office365.com (2603:10a6:10:230::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6768.37 via Frontend Transport; Tue, 12 Sep 2023 15:10:55 +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 DBAEUR03FT011.mail.protection.outlook.com (100.127.142.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6792.17 via Frontend Transport; Tue, 12 Sep 2023 15:10:55 +0000 Received: ("Tessian outbound d084e965c4eb:v175"); Tue, 12 Sep 2023 15:10:55 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 430d4a38f86e5ad4 X-CR-MTA-TID: 64aa7808 Received: from 85634adf11cb.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id EB2F8E89-6DB6-4D3D-B109-2FE2844B47C1.1; Tue, 12 Sep 2023 15:10:49 +0000 Received: from EUR02-DB5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 85634adf11cb.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 12 Sep 2023 15:10:49 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RFD0ZXj4Q9ICjRxUje6fR+uC5L/eRbP7TEKjxgMv62bioy4PhPjcgF9eoglB5PI3BT1Z0ESjXCbrjpjcWP7t5a8bRstHSvO+VeK9YyF0RO+nKLgCMtdSzdmxWnG/RyIMzBjZKhXzLD0BUtwY2VpqDh0YcBZrhluLvWQffPpc42VPYoeSRk+PRkrDF/appvRTesLXPddS6x58SjpfZLt7iV6CRfSWNebECRDZo2exTnOtUBYxZOX/36FWUGAzqSFXRIovSZrtLVfX+YmCXp4BL4xzSHJZYxeO17IuasF+xsdxSlZZr0X6zKNRXI5ccl4KCX1I8jX+CnwfYqBPeb37pg== 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=7gJJ15HVTP5nzIrGMX156qUB4RA/sVrV3lzww+7mWqo=; b=R/5G08UXiYxfzlJzJkkTdSKgn2tFJISBh29seP4qIGlydAnHMv0VVKIwcW0Eb3UXEOb2A5qR1wCIRqFGz59qaMyB/WJzM+/X4SADHwWssdFwWXKmh731JV6pWbN7F8zNXxdbAOSAzFpRClIOOnJq2YGw2wipk3qJTDz8+WTRvGUpV30G9GLSviAe3ePgmdfEmSchOrKluHiPnD/DJtHKge4qZGhp4W+EqN4ldacbxkT5Eg2AiSVmIC/73QVg5lrynrzpYxziF/5+KVwDpvTdFgcHKChFXKa9wMhYs/8e4gZGJrc1yQusY80R0RG476ElamqTyS+Hj/sSxJiuPixSkA== 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=7gJJ15HVTP5nzIrGMX156qUB4RA/sVrV3lzww+7mWqo=; b=kaAeBrR4SKH6jqHsvzshJFC0pJSdYBI0GNcCgfv2sViGBh4toX8cRoZLCEGFvcj5oc9dZyAipeDzH+NSHF9IS1wO5gLg19vc/0dYub62IELxNAhwEFxvZQnNn/eRvtG8vF49NMC942Zh/X01SeFa+Iqtn7vEz12EGrsRoKvFemU= 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 GV2PR08MB8725.eurprd08.prod.outlook.com (2603:10a6:150:b4::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6745.34; Tue, 12 Sep 2023 15:10:47 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::7743:60fe:4859:2df2]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::7743:60fe:4859:2df2%6]) with mapi id 15.20.6768.029; Tue, 12 Sep 2023 15:10:46 +0000 Message-ID: <51407aa1-ceba-4abf-135f-ad63ce86e038@arm.com> Date: Tue, 12 Sep 2023 16:10:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 Subject: Re: [PATCH] gdb/tdesc: Don't assign custom-group tdesc registers to 'general' Content-Language: en-US To: Andrew Burgess , Ciaran Woodward , gdb-patches@sourceware.org References: <20230907170752.28639-1-ciaranwoodward@xmos.com> <87o7i7ijt4.fsf@redhat.com> From: Luis Machado In-Reply-To: <87o7i7ijt4.fsf@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0169.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18a::12) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: VI1PR08MB3919:EE_|GV2PR08MB8725:EE_|DBAEUR03FT011:EE_|PA4PR08MB5918:EE_ X-MS-Office365-Filtering-Correlation-Id: 8c7747e7-933a-498b-31ec-08dbb3a27674 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: bwXvhhy6rzLyRFpjqrE/0U+WpP9Hk7Z6KcD6/BBggd5W4ta2y70xtZFJ8AAvOFEI12Fmm24izcbR+2u8w9buyCZwfSUbr+TPfOZvfUVWvXIRdej04UGc9//nBsePwj453ZG59CxExukJZ3fkxY0VxWfbTiM+80XMMb0XHBlB0BttQ3uNPqYCjc95JAWHuhc/EddWSXSdEp2HihvJGTWiahByGfeBme61P8boq+63uS9P0CTZ1sCRtCuK/4LhGWNKleaLCER9nME3sDnAm7tGfMFCOgnTr000X4X1OYud2QLeCyz9talgsVHE3u8JWmMn8m5Uav+VN3bD7/dmk2PZw7VWhXPuS+M7Ft8aik6vvuJ7LII39Ua9rELSer/RmqiDU76e1WZsh7rqDBN4eX0/6g/TekrnHZbgI2qGEcLvKotLnvM/hIg5u8jsOsD8VRHAU+AMNs6ekozEa7hkW09GgnIKnW1bigmtAV4x5J2r5NFxApnFEbXwqSkvkttvcvrustcZ+QKQ7AlHY6RsVnZCVosvsamMzD75MubD42lMuyyr1I5zp8OmVaYnik4yR3MkuYlzBuBl+fHxHgg24dHEzO85hF4qCmzbH+EQSplEDls5tnCOKfI2C4g6vkVUxyfF4lben95Lfiz6pT3vlYBwSg== 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:(13230031)(366004)(136003)(396003)(376002)(39860400002)(346002)(1800799009)(451199024)(186009)(31686004)(66899024)(53546011)(6666004)(6506007)(6486002)(41300700001)(86362001)(36756003)(31696002)(2616005)(38100700002)(26005)(83380400001)(478600001)(966005)(110136005)(6512007)(66556008)(8936002)(316002)(66946007)(2906002)(66476007)(8676002)(44832011)(5660300002)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR08MB8725 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: DBAEUR03FT011.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: eeddd320-b592-468f-53bf-08dbb3a27077 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: COPbXj2sy/4BxwKXBcXDCE4sTXs++3FB8Gbp2E9ivzbifhFQoZsbi0hwTFvUkA3XIyGBt3gDwzFGeislLydjHaK0OY/+HwgF4agwGkJ6FoBd+iMVn+cMMmLDmi1jXe7Gwz30jGmxvdjzfCx1SCCGnozwAOMZWrXadD2u00CN/iaIFabKuDR74Cb4BfZ2DM5ZE1YJeQFetVtITW1PjYLOs9vuc41cX81A72MhP53jnBJ704OQ6aKAOGndF4KJ5hoNiMbtt05WafdvUU9afbaHQO0oqy0tWeY2GW9UkI7X+VBYTUtel9nLKVm9WbqUp1qkIYBlU31D6H8VwkZ1Q2vnCtTDz1e3vGVB8qflFgmoLD3Fu5XOWmY2Epd1JtbCs48Y7KbiPMHBRStNb1d9W1jeuxovwjjmcBUAFXAeWggVbVv507qpVuKfgvzJN3WHUgpUBoDRdb7B1qOtWPENGMqZomWdXRJ0l/UYWYq2HJOWPBcd0f54CSjeP7ffrYbVKPY3jakbKqY6BMGUYaj6IHW1J/kWRnicDwyVdLPRDuyVFqqHcn66zzNJz+HxKiMOnbTijARU7zAPfWh/75ivCFfszx+YGJsdyNcIdsjqDxGwbt6Z4oA4eRPa9PcnA5FuU4CiIPBK4/2+Eb0r9uPx1PfK+2klmXpI+kAWCgAAJhx3L28fA2E7nBdgeoWWxgF+9+YShr+stSaVuXFrr+BdA42BEgiQwgnuj/G6TUgiqBNzpeGiBY71RebeLFSEeXunrIX06KF6ftJp6T3RYV7rw0ZBgw== 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:(13230031)(4636009)(376002)(39860400002)(396003)(136003)(346002)(1800799009)(82310400011)(451199024)(186009)(36840700001)(46966006)(40470700004)(31686004)(66899024)(6486002)(6506007)(6666004)(53546011)(356005)(83380400001)(110136005)(40480700001)(36756003)(40460700003)(36860700001)(82740400003)(86362001)(47076005)(31696002)(81166007)(26005)(2906002)(336012)(41300700001)(6512007)(966005)(478600001)(5660300002)(70586007)(316002)(70206006)(8936002)(8676002)(2616005)(44832011)(43740500002);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Sep 2023 15:10:55.6301 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8c7747e7-933a-498b-31ec-08dbb3a27674 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: DBAEUR03FT011.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR08MB5918 X-Spam-Status: No, score=-13.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,GIT_PATCH_0,KAM_DMARC_NONE,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,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: On 9/12/23 14:48, Andrew Burgess wrote: > Luis Machado via Gdb-patches writes: > >> Hi, >> >> On 9/7/23 18:07, Ciaran Woodward wrote: >>> The 'Target Description' mechanism in GDB enables the target to >>> supply the full set of registers available on the system to gdb >>> in an XML format. >>> >>> This format enables setting the 'group' of each register, such >>> that they can be queried using the 'info registers ' >>> mechanism. >>> >>> However prior to this change, even if a register was explicitly >>> assigned to a group, it would still show up in the >>> 'info registers general' report. This is unexpected, and also >>> disagrees with the comment above the tdesc_register_in_reggroup_p >>> function, which says that '-1' should be returned if the register >>> group is not-known, not the register group is known, but differs. >>> >>> There was a previous change that did address this issue in >>> aa66aac47b4dd38f9524ddb5546c08cc09930d37 >>> but it also caused registers with *no* group in the target >>> description to be removed from 'general', so it was reverted in >>> 440cf44eb0f70830b8d8ac35289f84129c7a35c1 >>> as that behaviour was used by some targets. >>> >>> The change in this commit enhances the usefulness of the tdesc >>> 'group' attribute for adding system configuration registers, >>> of which there may be hundreds - very inconvenient to request >>> and print on every 'info registers' call. >>> --- >>> >>> Email archive link to discussion of previously referenced patch: >>> https://inbox.sourceware.org/gdb-patches/20200120155315.30333-1-shahab.vahedi@gmail.com/T/#m0ce2983153b2f482b66461ed6b97c4b287b09a89 >>> >>> gdb/target-descriptions.c | 7 +++---- >>> 1 file changed, 3 insertions(+), 4 deletions(-) >>> >>> diff --git a/gdb/target-descriptions.c b/gdb/target-descriptions.c >>> index cdedf88c793..c1bb03c3adf 100644 >>> --- a/gdb/target-descriptions.c >>> +++ b/gdb/target-descriptions.c >>> @@ -954,14 +954,13 @@ tdesc_register_in_reggroup_p (struct gdbarch *gdbarch, int regno, >>> { >>> struct tdesc_reg *reg = tdesc_find_register (gdbarch, regno); >>> >>> - if (reg != NULL && !reg->group.empty () >>> - && (reg->group == reggroup->name ())) >>> - return 1; >>> - >>> if (reg != NULL >>> && (reggroup == save_reggroup || reggroup == restore_reggroup)) >>> return reg->save_restore; >>> >>> + if (reg != NULL && !reg->group.empty ()) >>> + return (reg->group == reggroup->name ()); >>> + >>> return -1; >>> } >>> >> >> Yeah, this is a hard one. Unfortunately the outcome then was that we >> have a number of debugging stubs out in the open that advertise xml's >> with less-than-correct group information. >> >> I think even gdb, to this day, is guilty of that. >> >> Though the patch doesn't regress things as much as before, it still >> makes the 32-bit Arm gdb drop the fpscr register from the general >> display (info registers). >> >> Depending on what others think, and the benefit of not having a bunch >> of system registers show up every time, we could cope with this >> particular regression. > > I took another look at this today. When you talk about the 'fpscr' > register, in features/arm/arm-vfpv{2,3}.xml the register of type 'int', > so would be in the general group, but is placed into the 'float' group > with a line like: > > > > So, to me, fpscr should show up for: > > info registers all > info registers float > > But not for: > > info registers > info registers general > Yeah. I'm not entirely sure how that came to be, but I suppose it gets displayed in "info registers" because of its type, even though it is in the float group. In any case, I don't think it is a big deal, and we could change/fix this. > When you mention existing stubs in the wild that "advertise xml's with > less-than-correct group information." -- are these stubs sending > something different to the above? Or are they just copying that above? > For 32-bit Arm I think there are both cases (the same as gdb and others somewhat different). But it is difficult to get our hands into all of those examples. > If we did want to retain the above functionality, then we can just > set_gdbarch_register_reggroup_p to point to this (untested) function: > > static int > arm_register_reggroup_p (struct gdbarch *gdbarch, int regnum, > const struct reggroup *reggroup) > { > if (regnum == ARM_FPSCR_REGNUM && reggroup == general_reggroup) > reggroup = float_reggroup; > > int ret = tdesc_register_in_reggroup_p (gdbarch, regnum, reggroup); > if (ret != -1) > return ret; > return default_register_reggroup_p (gdbarch, regno, reggroup); > } I suppose that'd work. To me, the fact fpscr is showing up in the general display looks like an oversight. This might also be a good opportunity to make the register group information in the xml's more accurate. > > Thanks, > Andrew >