From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from CAN01-YT3-obe.outbound.protection.outlook.com (mail-yt3can01on2076.outbound.protection.outlook.com [40.107.115.76]) by sourceware.org (Postfix) with ESMTPS id BF2423858C62 for ; Thu, 30 Nov 2023 21:02:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BF2423858C62 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=efficios.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=efficios.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org BF2423858C62 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=40.107.115.76 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1701378179; cv=pass; b=WoQK0o8XL5V2O4IklrkGNppZnsEb70OvsBlS55L9gDexgxb2azBlGxOJFuLAcuPo+rqTF5KKbEfPQNLhvs5zOmHHUcDwypA5Va9ORuQFnBB2RyLVpJYkCSRQKPW2J9tLQrlqjRxy75fb0T2bRqQ2oIWuhiWcL9bq5EUfO5LnQVc= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1701378179; c=relaxed/simple; bh=BmvD/ZLsN3OFq7Am9SO99LrGPi8gvV/f+UGFhV3lM3o=; h=DKIM-Signature:Message-ID:Date:Subject:To:From:MIME-Version; b=Yu1uTny3mO5ZC2Xm9OnKevxODTwskXBplH/dcg4DKpQDn0Drge0Ve6qytKdI4ueysAAM9NanROfr27Enf1VwhQ4M8ZMtkOaS5x79N3H6N6JQufAAGUFPhnxOd69zlJnY/co5kvBoIAg7EAIkv+YAoGgJFmr5yh7E4Jdw3ch2QvE= ARC-Authentication-Results: i=2; server2.sourceware.org ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nDs8+8qMExD5jGSlJPUXRTHFcreOZTwSZb0BfWZEvppho5Bq0qSID2y55bbStVv/1Eppz5EQNakmcB7XmrMapDNlUdQX9QOJedjtfFPPq5aH5TUh6qdiR2Zx6PQ4t/h8U7nbYwHLANG2iqL6EZVkNHI7O7XhVv0OIJZFcJ2/wIbXhMLJTtLIxNV4Kx/7k/qBzdKS0vEA0UKfOvxtVCq8W1laEF5CepWANzCsXTWUGc9HIs7esgLlG+Bo2nh1w30vJSNHoSh7f+dqTCt7BYq1gp5E8S3kF08OYPPLtBk45nTxVVmifPLmiCSF1nnZBxGxGKkgq1MigK3JQ65Vs2G+uQ== 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=faACglzEPEdZziBejGbnsgHZuNfsva2ii+FzQTWJmr4=; b=EjSzP+OnyAtcGsMwOLgNmXw9MtirzE6V2nPqsFYIfXuWYaaR8ZOvQt16VFdPM4b9awAjJwdZwGicHXygcSufu/d7I8KbcoD675cxl+vMulYfPRcXuKpN5SFHGcUdCXJv0Z8FQn+cdJyu/KMf6m0+ppj00gspCLCDrWonLFe6GDhKJW1lx4CN+vadxQTJdzY9Bzj8FR7Qyg7L1VIei4w/PcEuE0CNWtHSObEITHErazieqzRrTp+wMK0BL2rBagtnBkiXk6/AwFLxooYnv5gU02kxjn5KXU9cajzJaekysC+7AdC3VX8ONRcePHuYBMugffz/Vzwse+E0ljf8u5NVmA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=efficios.com; dmarc=pass action=none header.from=efficios.com; dkim=pass header.d=efficios.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=faACglzEPEdZziBejGbnsgHZuNfsva2ii+FzQTWJmr4=; b=lxzPTPB1JM44wDYArLaw60nofVnaZzJ+RrI2g/P/IbVuS1Ajs4ojPiD05EtRq64uzFFE6N7862cXNr3RWulJOy9xENOwCFXdOg9bPUbHzcVVoU9sratqE7ComjxcR8FQQopYoOuVtWS1vNpcIAbdJj582tLyVTDi/7r9/gM3zJJdKF2DpzjEMn2AGOyiLCgcr1HUzGGd1Up9wME3LfpN3YYWYXexQ3N/ebxTXKtuHB7bH2NPQ0t4bqj0TdK7gSmdMPxyDc8H4pdVhv+kTwXfBq2iqO/m0LI8Dsv+bsdwrVan3WQneF8UC/VGAjSc52WnzrODtfln+JQ028CEwJHEYA== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=efficios.com; Received: from YT1PR01MB2828.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:a::23) by YQXPR01MB5420.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:2e::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7046.22; Thu, 30 Nov 2023 21:02:52 +0000 Received: from YT1PR01MB2828.CANPRD01.PROD.OUTLOOK.COM ([fe80::9378:63a0:1c28:2df7]) by YT1PR01MB2828.CANPRD01.PROD.OUTLOOK.COM ([fe80::9378:63a0:1c28:2df7%3]) with mapi id 15.20.7046.023; Thu, 30 Nov 2023 21:02:52 +0000 Message-ID: <325c5da5-8cd5-4d75-8d7e-3a832a5fe1cb@efficios.com> Date: Thu, 30 Nov 2023 16:02:50 -0500 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 02/24] gdb: use reg_buffer_common throughout gdbsupport/common-regcache.h Content-Language: fr To: "Aktemur, Tankut Baris" , "gdb-patches@sourceware.org" Cc: Luis Machado , John Baldwin , Andrew Burgess References: <20231124212656.96801-1-simon.marchi@efficios.com> <20231124212656.96801-3-simon.marchi@efficios.com> From: Simon Marchi In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: YQZPR01CA0094.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:84::22) To YT1PR01MB2828.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:a::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: YT1PR01MB2828:EE_|YQXPR01MB5420:EE_ X-MS-Office365-Filtering-Correlation-Id: e09232da-6a47-4af6-c340-08dbf1e7b74d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: yNFdqYHTK/mN/Z41U3eKRinQSV7RDpBKIHRKdBEkHaeGtoQMAnXRtRDF2NxKgd7Ib2hbZcb/mQrF9ks3BlIv45Hz+W56Gu6TvjE4dkblpqlMFOzrsgDzJW6mHKtIuU/lCwbXYL5kIsxZTLkk5kzgXG7sSi33GJJvAVOFZVWHDhFD8JZWORK/+B/nOj5VPmyc3EvdWWQbZTsnlxHRI9ymEKBY5tgVQ8tnO+iSqNlbWr5ah6NW1KjbGzmF+lpwdAZxilVv+AMaAWP31wCL58ipAiUwD5Hf83cKjGQbC9us0W6CVDNiXhOftDvMye9JRzgFMEJyxymmf+GVoIWvS+WtyaLqE+LXL4ozgV7PvOPvW+NtkWh084dLkVPBKlLNsW4aa4RZ8ud68JSO9EMDmKhgBZvmUgH2FaEgIFjjuoIxAO4whRXzqaxtn9cqgE+IPXqvnYEtYLVpkDLI9wUedxDdeNe+HZUHRhhOeIi6jlv21ccpDDdPx+ecXvhNhL78P/xahnajLuLu0r6HxEWlF8O2/dIGFuGRdsVwliw7jakxAPTdNVnd9P+Q32T2sVFWR01J7r3VmRO5/GIyY/wB5Zt4nZ294khjVYVxZqUfr+CfPHVLJTiggQ8NElz9F4YkNBtVirx5J4TamyDXsHdaB86orw== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YT1PR01MB2828.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230031)(366004)(396003)(376002)(39830400003)(136003)(346002)(230922051799003)(451199024)(1800799012)(186009)(64100799003)(31686004)(4326008)(8936002)(41300700001)(110136005)(54906003)(316002)(66476007)(8676002)(66556008)(36756003)(66946007)(6486002)(31696002)(44832011)(26005)(478600001)(5660300002)(2906002)(966005)(53546011)(6512007)(30864003)(83380400001)(2616005)(38100700002)(6506007)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eGNYeCtnS2dpQzlLL0pNSXBOenZKdGZpQmNZclRueWY1QVZ0QU5oMjJtNDFB?= =?utf-8?B?OHpxZ29WZkwzOURlZE9GR1padFpNUWhnUzhCUlR1YjZLbEJJZUlkeTBlYzNa?= =?utf-8?B?VWpGd1NsTDJiVkMycDNZRGVEbXY5dUxwejNIUXEyWE54cEFTS1JpNXZRTjlo?= =?utf-8?B?RDZqRTJQR0tsZjlpcnJBYmpBczNwL1o5TlRJQnFnOTRTcVBYQzhDZ2E1L1pj?= =?utf-8?B?REgxUFVORWRteU1LUGxQSEp4a3hoNjI4QTRRSWtQTmpKS01WVDNvcjBEZUlk?= =?utf-8?B?bGFsNmw5NlVIRmlsL0V6MWxTZnNHVW9qNmk2dk1Yb09GYTdHUVRXdGREUmFr?= =?utf-8?B?WlgzZnFmcmdIaTVqV3lneGR2YlB6RXYvdkRFMjNPM1I2UVZnL0VpdTJ2RDZ5?= =?utf-8?B?QmhKRkJ1c250d2hjeFZMZmNYdGQzblgrcHZ2MzJyNjhTa3hBRFZicXdEL2Vm?= =?utf-8?B?NlN0N0NwVHRCMFA4ZFEyL2NJYVRWd1hUK2xLT09nYnVoT0tOeWhTSlNpYXMz?= =?utf-8?B?YnR6OTdhbkZyR1pLUjFUaExyNjltajJNQ0U0QkpLUzc0cndXZU5ha1dFL0lt?= =?utf-8?B?QlpNaGNKbFZJdnZsc0VreGQxMGNWSERyOWhqeG0zVTZkRi9JbTBJcW11RldO?= =?utf-8?B?RVpMSmZ2Vi8yOGY0OU5tOTMwSlZLUDJXeVF3UDFqWEJFdEZSTkxPbVBVTW5K?= =?utf-8?B?aFBHdEttaXlHNG5JajRJTVZ6ZFhraWVoWHlSOVJUWkhTMHVlekovZ0g2eXRq?= =?utf-8?B?eThuanpONWVLbkhwOStKeUh6S3JYL1FRYTV5K2VzTURQcnozNUNCS1kzeHpm?= =?utf-8?B?clRkNXhZMDZobmFVenl4VHFvQlplMlBZRVNYU3U5Vzh2SW5RdVB5UnMrM1dB?= =?utf-8?B?d3pQcnRZRkJpMHByckRYZkU0ZjBicGg4MHI0V3QvNmNic2JjcW5EOCtZTlNC?= =?utf-8?B?dnJnMUFEUFZkSTkySkNMeGdqMEFKZEZuMGFDYXRNOU1tTDFJakdXY1pyaWZE?= =?utf-8?B?dFhBeUFIQ3I4TS9YdysyTjRJMXYvbytTYnlpQzBBNG5YckYvUEdiNlNkSmJO?= =?utf-8?B?TEh2MVpudmZLakx1VEJCb2pBQ0NRNzJRZVBGeXY5d3UxeENuT3RYZkE0dlpo?= =?utf-8?B?WDV0R1k5MUhwbGJIeDhrSW5NVHRpbUwrTmx4REZlZm1kc3lMY2o5MjB1aXdS?= =?utf-8?B?YjMwZ1hXb3VkNVVPUVdjL1JGaWlPTExhSmFXTTJMYVJIT1dRUEtCVE92Lzlw?= =?utf-8?B?TS92a28zMEpXbmNnK2kzNWtoSXlVNk5ZdXl0dHFLekRiZG9Lb0JHOHdqMG0w?= =?utf-8?B?RGE1K0xya0I4YTVibEdoMDBxeWpXQnViSWhMNmRoUTlhK2JESytlVm5kamJM?= =?utf-8?B?bytIT3F3MGhoRWkxam92aUNiYWEza3d6T2RrQjYrTktyb3FqZmgySzVvRUpG?= =?utf-8?B?dUowOExyd2NrYkUzMWVESjh4aFJtY01uYk1jNTRZOFJFWGRxNUpJdFpjVGhI?= =?utf-8?B?ckhwZFg4c3lxVWRWa3BNZ094a1c1NWZxaHBPTXJrZWY4cHpnOXFOclg4bCs5?= =?utf-8?B?L282T3FncUR2VjVDQ01EZVMzVWxjbXJOTjRLQlFtdXdxZVUvU0d0Y1d4SUFI?= =?utf-8?B?a2k2QnNhUVY2M2s5M0huUTdOdGZJa0ozbGpSRGJvVEtPalp5Mlh2cUZsOHdm?= =?utf-8?B?K0R3M3QwdDhGWDcrOVhzL2M0S0Q0VUxxYVVrK1FqRkhFaWRxY2VyUDQ0WnUv?= =?utf-8?B?YUdYTW5yYkRvRlJUWjVueXBUODFKakRMdFJ4SjAxVGtlWHpYZzlkNE1xNTVy?= =?utf-8?B?d0ZkTU02cUduaVNyQ0FVdkhrYUZwdlRQSmZFbVYrazFFS1NjMnRFK3Blb2lq?= =?utf-8?B?RG1zZDJHOG45S2k1UE5IRWVsaElCNndNdmhmQzBJbXVqYTZOb3Z0S1B6YmhM?= =?utf-8?B?QnowRlM5dW52YTUvSFpodkpiNUVaTnQ0R3BLaFN1dlNwSktnMlE4cHdYMi9v?= =?utf-8?B?MkxwcmpLWHUrRGE4Rk9NS0VLeThEVUN0MVJPRzBndFg5N09aRFdVRzUySEtv?= =?utf-8?B?SmJuZ1QvaWxBK29VYW8xYlNIMkFoTEdJUVdtTk1IbW1qdmN1VzgzTHM5VXU4?= =?utf-8?Q?Se8/jbjB1aFYXnKunrKQPGBPS?= X-OriginatorOrg: efficios.com X-MS-Exchange-CrossTenant-Network-Message-Id: e09232da-6a47-4af6-c340-08dbf1e7b74d X-MS-Exchange-CrossTenant-AuthSource: YT1PR01MB2828.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Nov 2023 21:02:52.3142 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4f278736-4ab6-415c-957e-1f55336bd31e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Ur3g+dUKaWPlo5fZItP3+/pEghB7edQRQcNoH1g3Lim4e5CGONQk8QkK6ecEgFw8YAmWuTLeiQrTzX0uAaRerA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB5420 X-Spam-Status: No, score=-3038.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 11/30/23 06:45, Aktemur, Tankut Baris wrote: > On Friday, November 24, 2023 10:26 PM, Simon Marchi wrote: >> Right now, gdbsupport/common-regcache.h contains two abstractons for a > > Typo in "abstractons". > >> regcache. An opaque type `regcache` (gdb and gdbserver both have their >> own regcache that is the concrete version of this) and an abstract base >> class `reg_buffer_common`, that is the base of regcaches on both sides. >> These abstractions allow code to be written for both gdb and gdbserver, >> for instance in the gdb/arch sub-directory. >> >> However, having two >> different abstractions is impractical. If some common code has a regcache, >> and wants to use an operation defined on reg_buffer_common, it can't. >> It would be better to have just one. Change all instances of `regcache >> *` in gdbsupport/common-regcache.h to be `reg_buffer_common *`, then fix >> fallouts. >> >> Implementations in gdb and gdbserver now need to down-cast (using >> gdb::checked_static_cast) from reg_buffer_common to their concrete >> regcache type. Some of them could be avoided by changing free functions >> (like regcache_register_size) to be virtual methods on >> reg_buffer_common. I tried it, it seems to work, but I did not include >> it in this series to avoid adding unnecessary changes. > > In the series posted at > > https://sourceware.org/pipermail/gdb-patches/2023-February/197487.html > > I had proposed some similar changes (not for regcache_register_size, but several > other functions). In > > https://sourceware.org/pipermail/gdb-patches/2023-March/197724.html Thanks for pointing me to this, I haven't been able to keep up with gdb-patches lately. > Tom had said: > > I haven't read these patches, but I wanted to mention that, over time, > we've been trying to bring gdb and gdbserver closer together where > possible. And, I'm wondering how this series fits into this. At the > end, are the two register caches more similar? More divergent? > > I'm not necessarily saying this is the most important thing, but for > example what would be unfortunate is if the two ended up with similar > functionality but very different expressions, which would make the > sharing of other code even harder. > > I was going to rebase the series and send a ping. Given that your > submission is likely to be merged earlier and based on Tom's comment, > I can wait and do the rebase later. I'd be glad to hear if you have > comments/directions. I read the cover letter and commit titles, it seems nice. I agree with Tom for the general direction, if GDB and GDBserver are going to have the same functionality they might as well share them. This could then help move some code that uses regcaches to common subdirectories. But sometimes the concepts are really specific to one side, I think we should not force it if the concepts are not compatible. But I'll have more of an opinion when I'll read your series. Since I have the regcache code cache hot in my head, I can help you with this series in the following weeks. >> @@ -653,7 +653,7 @@ arm_get_next_pcs_raw (struct arm_get_next_pcs *self) >> unsigned long this_instr = 0; >> unsigned long status; >> CORE_ADDR nextpc; >> - struct regcache *regcache = self->regcache; >> + reg_buffer_common *regcache = self->regcache; >> CORE_ADDR pc = regcache_read_pc (self->regcache); > > Here, the argument to regcache_read_pc is left as self->regcache, but ... > >> std::vector next_pcs; >> >> diff --git a/gdb/arch/arm-get-next-pcs.h b/gdb/arch/arm-get-next-pcs.h >> index e6bb8d832286..ec347f01b4fd 100644 >> --- a/gdb/arch/arm-get-next-pcs.h >> +++ b/gdb/arch/arm-get-next-pcs.h >> @@ -24,6 +24,7 @@ >> >> /* Forward declaration. */ >> struct arm_get_next_pcs; >> +struct reg_buffer_common; >> >> /* get_next_pcs operations. */ >> struct arm_get_next_pcs_ops >> @@ -50,7 +51,7 @@ struct arm_get_next_pcs >> not. */ >> int has_thumb2_breakpoint; >> /* Registry cache. */ >> - struct regcache *regcache; >> + reg_buffer_common *regcache; >> }; >> >> /* Initialize arm_get_next_pcs. */ >> @@ -59,7 +60,7 @@ void arm_get_next_pcs_ctor (struct arm_get_next_pcs *self, >> int byte_order, >> int byte_order_for_code, >> int has_thumb2_breakpoint, >> - struct regcache *regcache); >> + reg_buffer_common *regcache); >> >> /* Find the next possible PCs after the current instruction executes. */ >> std::vector arm_get_next_pcs (struct arm_get_next_pcs *self); >> diff --git a/gdb/arch/arm.c b/gdb/arch/arm.c >> index 4720c201c532..88737fc357f8 100644 >> --- a/gdb/arch/arm.c >> +++ b/gdb/arch/arm.c >> @@ -322,7 +322,7 @@ thumb2_instruction_changes_pc (unsigned short inst1, unsigned short >> inst2) >> /* See arm.h. */ >> >> unsigned long >> -shifted_reg_val (struct regcache *regcache, unsigned long inst, >> +shifted_reg_val (reg_buffer_common *regcache, unsigned long inst, >> int carry, unsigned long pc_val, unsigned long status_reg) >> { >> unsigned long res, shift; >> diff --git a/gdb/arch/arm.h b/gdb/arch/arm.h >> index c64a15600de3..b6c316191877 100644 >> --- a/gdb/arch/arm.h >> +++ b/gdb/arch/arm.h >> @@ -188,7 +188,7 @@ enum system_register_address : CORE_ADDR >> ((CORE_ADDR) (((unsigned long) (addr)) + 8 + (sbits (instr, 0, 23) << 2))) >> >> /* Forward declaration. */ >> -struct regcache; >> +struct reg_buffer_common; >> >> /* Return the size in bytes of the complete Thumb instruction whose >> first halfword is INST1. */ >> @@ -213,7 +213,7 @@ int thumb_advance_itstate (unsigned int itstate); >> >> /* Decode shifted register value. */ >> >> -unsigned long shifted_reg_val (struct regcache *regcache, >> +unsigned long shifted_reg_val (reg_buffer_common *regcache, >> unsigned long inst, >> int carry, >> unsigned long pc_val, >> diff --git a/gdb/arm-linux-tdep.c b/gdb/arm-linux-tdep.c >> index 8117d35a4d37..05538251612b 100644 >> --- a/gdb/arm-linux-tdep.c >> +++ b/gdb/arm-linux-tdep.c >> @@ -903,8 +903,10 @@ static CORE_ADDR >> arm_linux_get_next_pcs_syscall_next_pc (struct arm_get_next_pcs *self) >> { >> CORE_ADDR next_pc = 0; >> - CORE_ADDR pc = regcache_read_pc (self->regcache); >> - int is_thumb = arm_is_thumb (self->regcache); >> + regcache *regcache >> + = gdb::checked_static_cast (self->regcache); >> + CORE_ADDR pc = regcache_read_pc (regcache); > > ... here the argument is changed to regcache. It is not incorrect, > but I'm just pointing to this in case you want to keep it consistent. Thanks, I fixed arm_get_next_pcs and another instance of it in thumb_get_next_pcs_raw (moving the declaration of `reg_buffer_common *regcache` a bit higher). > >> + int is_thumb = arm_is_thumb (regcache); >> ULONGEST svc_number = 0; >> >> if (is_thumb) >> @@ -914,7 +916,7 @@ arm_linux_get_next_pcs_syscall_next_pc (struct arm_get_next_pcs *self) >> } >> else >> { >> - struct gdbarch *gdbarch = self->regcache->arch (); >> + struct gdbarch *gdbarch = regcache->arch (); >> enum bfd_endian byte_order_for_code = >> gdbarch_byte_order_for_code (gdbarch); >> unsigned long this_instr = >> @@ -937,8 +939,7 @@ arm_linux_get_next_pcs_syscall_next_pc (struct arm_get_next_pcs *self) >> { >> /* SIGRETURN or RT_SIGRETURN may affect the arm thumb mode, so >> update IS_THUMB. */ >> - next_pc = arm_linux_sigreturn_next_pc (self->regcache, svc_number, >> - &is_thumb); >> + next_pc = arm_linux_sigreturn_next_pc (regcache, svc_number, &is_thumb); >> } >> >> /* Addresses for calling Thumb functions have the bit 0 set. */ >> diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c >> index 7a93b0982478..d87d8e0fc1c2 100644 >> --- a/gdb/arm-tdep.c >> +++ b/gdb/arm-tdep.c >> @@ -7255,7 +7255,8 @@ CORE_ADDR >> arm_get_next_pcs_addr_bits_remove (struct arm_get_next_pcs *self, >> CORE_ADDR val) >> { >> - return gdbarch_addr_bits_remove (self->regcache->arch (), val); >> + return gdbarch_addr_bits_remove >> + (gdb::checked_static_cast (self->regcache)->arch (), val); >> } >> >> /* Wrapper over syscall_next_pc for use in get_next_pcs. */ >> @@ -7271,7 +7272,7 @@ arm_get_next_pcs_syscall_next_pc (struct arm_get_next_pcs *self) >> int >> arm_get_next_pcs_is_thumb (struct arm_get_next_pcs *self) >> { >> - return arm_is_thumb (self->regcache); >> + return arm_is_thumb (gdb::checked_static_cast (self->regcache)); >> } >> >> /* single_step() is called just before we want to resume the inferior, >> diff --git a/gdb/nat/aarch64-hw-point.c b/gdb/nat/aarch64-hw-point.c >> index 6747e61e0265..8e9a532cd2a4 100644 >> --- a/gdb/nat/aarch64-hw-point.c >> +++ b/gdb/nat/aarch64-hw-point.c >> @@ -137,8 +137,7 @@ aarch64_point_is_aligned (ptid_t ptid, int is_watchpoint, CORE_ADDR >> addr, >> alignment = AARCH64_HWP_ALIGNMENT; >> else >> { >> - struct regcache *regcache >> - = get_thread_regcache_for_ptid (ptid); >> + reg_buffer_common *regcache = get_thread_regcache_for_ptid (ptid); >> >> /* Set alignment to 2 only if the current process is 32-bit, >> since thumb instruction can be 2-byte aligned. Otherwise, set >> diff --git a/gdb/nat/linux-btrace.c b/gdb/nat/linux-btrace.c >> index c0cebbb2f02d..4369ff0ef782 100644 >> --- a/gdb/nat/linux-btrace.c >> +++ b/gdb/nat/linux-btrace.c >> @@ -284,13 +284,12 @@ perf_event_read_bts (btrace_target_info *tinfo, const uint8_t *begin, >> struct perf_event_sample sample; >> size_t read = 0; >> struct btrace_block block = { 0, 0 }; >> - struct regcache *regcache; >> >> gdb_assert (begin <= start); >> gdb_assert (start <= end); >> >> /* The first block ends at the current pc. */ >> - regcache = get_thread_regcache_for_ptid (tinfo->ptid); >> + reg_buffer_common *regcache = get_thread_regcache_for_ptid (tinfo->ptid); >> block.end = regcache_read_pc (regcache); >> >> /* The buffer may contain a partial record as its last entry (i.e. when the >> diff --git a/gdb/regcache.c b/gdb/regcache.c >> index 9dc354ec2b3a..7f1f07694d8a 100644 >> --- a/gdb/regcache.c >> +++ b/gdb/regcache.c >> @@ -180,9 +180,10 @@ register_size (struct gdbarch *gdbarch, int regnum) >> /* See gdbsupport/common-regcache.h. */ >> >> int >> -regcache_register_size (const struct regcache *regcache, int n) >> +regcache_register_size (const reg_buffer_common *regcache, int n) >> { >> - return register_size (regcache->arch (), n); >> + return register_size >> + ( gdb::checked_static_cast (regcache)->arch (), n); > > Redundant space after '('. Thanks, fixed. Simon