From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2052.outbound.protection.outlook.com [40.107.22.52]) by sourceware.org (Postfix) with ESMTPS id 4CD4F385735A for ; Tue, 14 Jun 2022 09:46:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4CD4F385735A ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=Sn1uacRFXmV3svcXncO8YGWqrXTqrWgWCLZFRTOy1Q8ki2SnXHOgvvMi9BRzXrdrGq3yfkTAaX3dhbPgh+7FrgVAji/pcubg7RRAWNE02dc0jkem+s/4b6L80aLK3VBWdcW6wE6QDvPwvqTimkaeHoWpyJCUrTcts7B+t/5R6sja994VOXi8Wsdw1va55V+Hzh77GtNhyrgftQPCDAULN78UbC4702el+RJLwijYVqCd0tum30Po2DQWoZ6GC1BA5IXvD1XH2HE0ay8OqlRHHYi8bWsKKAyZeE4JJe5FNxCU75jJ05S/F5pEztiy7kIxpql9Y+/XLZsTsUiM0vAlvw== 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=e8bjkTaDQYxs9FJzAZ2pk0B8OaueSdfkpv0fkvd2u4U=; b=S84lFyH94iOeSEcHqqeSi8p3vry3DfUJeDiW+0TUsdd8VoRr0/te4LrwbsE2nGJ6Riah3v/ApfwEvcgD1EqWUEJ7RV/NJkfd5isQVQrzU/+qvBQ/Fvr89WLFzjWWarfDuSHu8yZ1PA4bXYpqmpdl+KYcjyaRFI/rw4uJ/kd3cmyyE/sLivzAqRlYUrWRsZb2ke9gXDJgCNfpV0Rmejlf9yL9dPTu+BKJkU46GwzQMp8pOsERGCBDB1wUwmtj8oGrFuzvamjy3wn++sq25Riwq0fS7XAM7eHbGyyOkiTCNOaf5VLAHrtMu5xOX719CcOUFnv65k31S2ZVWJS9AhgcuA== 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 DU2P250CA0015.EURP250.PROD.OUTLOOK.COM (2603:10a6:10:231::20) by AM6PR08MB3208.eurprd08.prod.outlook.com (2603:10a6:209:4b::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5332.16; Tue, 14 Jun 2022 09:46:02 +0000 Received: from DBAEUR03FT061.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:231:cafe::4) by DU2P250CA0015.outlook.office365.com (2603:10a6:10:231::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5332.22 via Frontend Transport; Tue, 14 Jun 2022 09:46:02 +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 DBAEUR03FT061.mail.protection.outlook.com (100.127.143.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5332.12 via Frontend Transport; Tue, 14 Jun 2022 09:46:02 +0000 Received: ("Tessian outbound 1766a3bff204:v120"); Tue, 14 Jun 2022 09:46:01 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 317d5bb5100f16fb X-CR-MTA-TID: 64aa7808 Received: from c468b7d61f2a.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 771A8D99-108B-4913-9CC5-5F0CADDF3D89.1; Tue, 14 Jun 2022 09:45:54 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id c468b7d61f2a.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 14 Jun 2022 09:45:54 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=So8VwZSXvD1DpKeocVSJek69qS57A7v6s3zgtXZIfQ9IjVK4j/120MIgjZjbz3t42uZAXoToO+aCqHLfIEW3MIZpDnrhmHBe719ucikD9MZaJvLdS83I/bGtRpfzwWoyPfOMPPzrY2qsq9Mc8u07kMR4GlJjNnk4e1r5EHSiPYVVhDlgdkICFGm9dGICGu7e8DUGILhewPtRWrRfYfjvtlzWfA3ijry2Q1ae3tvT6lIbWwNJxr+zFiip3QCEg7jcXkTjxseu1RiCyvzSBCwP7HhtMD/qHwpUuwHf055nkjyif3NoZ+qEbmHuzVQR+lHjWVseINkfsqlxaUR8T1wrPw== 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=e8bjkTaDQYxs9FJzAZ2pk0B8OaueSdfkpv0fkvd2u4U=; b=nFR2125j/IdCUnNx8ZLyDoO0MO2USbZTwCTAnSY5c6/jf1Jsiyz1ks9n8occgzU1KtlL5wP/OefsOU4N3PKR4V4bI5GilAYEvrqqnWeCqZI24YKH1D/q0XSdYmC05NmogeMHbkgKoqgCwADrORh8L9Vt68IVJjld4/j5XNtEtfh9+bTwukBup6XORrZzknWOBAvZdZvTEEg5vEtpQTZ2BigIsBwl43bshdZDJ7deSrcvX28oCDJEyyOPBbOGVKNWkTvdtZAbKmhHEIXLI4BWLp2UL/AaruH40fUBX+6PW+6q+mT9AlTp0zPgeYfCrkRRAuy93IhijFd58DB4qp7+xQ== 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 AS4PR08MB7407.eurprd08.prod.outlook.com (2603:10a6:20b:4e2::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5332.20; Tue, 14 Jun 2022 09:45:53 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::d9c0:539c:a641:5735]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::d9c0:539c:a641:5735%2]) with mapi id 15.20.5332.022; Tue, 14 Jun 2022 09:45:53 +0000 Message-ID: Date: Tue, 14 Jun 2022 10:45:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCHv3 3/6] gdb: select suitable thread for gdbarch_adjust_breakpoint_address Content-Language: en-US To: Andrew Burgess , gdb-patches@sourceware.org References: <9645de63bf2655cb1d03b5fde9ea0eb9379941f6.1655136816.git.aburgess@redhat.com> From: Luis Machado In-Reply-To: <9645de63bf2655cb1d03b5fde9ea0eb9379941f6.1655136816.git.aburgess@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO2P265CA0381.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a3::33) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: d6effcde-7673-420a-cfe2-08da4deab169 X-MS-TrafficTypeDiagnostic: AS4PR08MB7407:EE_|DBAEUR03FT061:EE_|AM6PR08MB3208:EE_ X-Microsoft-Antispam-PRVS: 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: PplzKIFFT7xZCA7R9R0Gbbx3oR6SVuSVPSzzcjR/Ayr3Yj3TkF02pnVqzvj60hCs04jq/AOVJn94Mi48xGtxh8loB3cnasA2jp4YmMN8SzVptnrcSWNU3IRtozaMRIXcQ+3I8HAnIgOvNrC7hJloRI4+IueXxFI6ECroLhhcsLD7+9bbriVaYf4rZKatkn4wWjL7rij311UdqRCG0BEoPmdMrDBdTurdvQZev3o7L/y1fsWAIw3Fg03Jz0IGInJCKLDn26gHlbQXdfQeAy3UAiv3XbF6t+tpGDzO5puxuAkTnQn0MggncUZvIdrby1MhQP2p8GaAmZ7rRGv+Bp3wCMZe/zd3nX4pcOZm3e8grk7L7MJWrpRKKdyLgeMyfXT+ggs3SiE4IEvZDkcsVzGJQH6yowuEvNe5EDKxotaafmZepOvsWcfaGFD81UK7t9/6QuPXcAfF3IOZB+PpYMw7H4sdr0h10j5wHQOmL//ZzvEiK85mcCdLDBbPpbZBYsBML/e3bOWsF7z88R/3FuHTsgoirX7Ll2ruL0AGLHh048lB7p2SnE3cpN5ysKqqth2eNFf4Sd/P2iibQseXS5RunticTUCvg+MK8+uD8EJYYahtJIx9vYVSBRJozGbQhSwMsYzLXzvtTiK/W8x7GyvtncXW/Yi5PvevWCsLz2a76RLTQ1kh9Kbs5xPGapEn7Yu3QRDWGu1aTVq1FgfwF9w50Ed9XcGOVjnicz5E/RGhPVDm7n8xOlMkPtppehU74TE/rHRs6cgpJWKcZ3t4Ice/vPq8ySDS8ERxwV98NdG99y3G8p8FpyMcMBDxSVw+sCwd 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:(13230016)(4636009)(366004)(38100700002)(26005)(31686004)(6506007)(8936002)(84970400001)(6512007)(86362001)(31696002)(316002)(508600001)(44832011)(2906002)(6486002)(5660300002)(66946007)(66476007)(186003)(8676002)(66556008)(83380400001)(36756003)(2616005)(53546011)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR08MB7407 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: DBAEUR03FT061.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 8dddf624-8a60-4738-4f72-08da4deaabe2 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: k1o79YQUpWwGh+b2jskUN4sRnFOwD8Vvza3R5W2kRJ2P/pjv2YNQVQUoLp2D45xCeIUcw6O76iJvXq6w+ZlvOxNwLg6T1+wSJKeqAXsfqO5l0G7m1VEqajD/YUNqBxMTF2I06tcIOzdt/OmjGU8DjyHiOEVOgws98grKyXkAhF8qDznGBGpkUrHQLL9qA/Ziuq293JjeHPmrtCoP2s5gXA1hHxVFLx8qxwz8lE/bJ7ahg3jXnhZRRCJ6zRzNtJ0A7xF6tr8HY59Y9Zip0Y7/qihewnztD4qQz3DKYf6lBssZfrhP7UAco9uHBGTTYVLooHt1lAmPl29Q9M49rUGtukjLLZx5qh89jnw2C5r31pbpncwVoo8a1mJSvGGBdv9ArIneKsTau823Gpak6m6Npb4RzipAf1RrBxPfX70Xy3eG/8ffozBYRnTxHIypZtO99/8pg3HvjPIVeBEX83t6zdNh6BaWpGpFaIeQ8gaRgSoSBRbcDSQnfw2dj+RrfM0serFgFl32r3Iv2LcLRDrfA0Yj2tenYKsaFCehgrwLvk3gwUKNVtWtCYu3vv5Eebc7eSaMaob6ilPw4bP073c+piGz+B+eiX4NsqBSrIDy2vm9eynwI7udmuQGbWFHJiIENnxBcRr3EEo7dyTae5jJrifhqUrAbmgLCxgz3y4dt92Md4yd9igqAXzIF1hZtwSU0sQ8GMcUvWstmkj0x/BrQ0lIC0HKA1TuovsrItA6LUJ/9Mpsgy4JsCFrK3HQADm/M531JqSV7Mtc0itzoYF8AykasV8htnPshWv4l7Han0E= 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:(13230016)(4636009)(46966006)(40470700004)(36840700001)(47076005)(40460700003)(186003)(2616005)(336012)(81166007)(31686004)(356005)(36860700001)(70206006)(8936002)(5660300002)(70586007)(82310400005)(8676002)(2906002)(44832011)(6506007)(53546011)(84970400001)(26005)(508600001)(6512007)(316002)(6486002)(83380400001)(31696002)(86362001)(36756003)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jun 2022 09:46:02.0534 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d6effcde-7673-420a-cfe2-08da4deab169 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: DBAEUR03FT061.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3208 X-Spam-Status: No, score=-13.2 required=5.0 tests=BAYES_00, 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, T_SCC_BODY_TEXT_LINE, 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: Tue, 14 Jun 2022 09:46:10 -0000 Hi! On 6/13/22 17:15, Andrew Burgess wrote: > The three targets that implement gdbarch_adjust_breakpoint_address are > arm, frv, and mips. In each of these targets the adjust breakpoint > address function does some combination of reading the symbol table, or > reading memory at the location the breakpoint could be placed. > > The problem is that performing these actions requires that the current > inferior and program space be the one in which the breakpoint will be > placed, and this is not currently always the case. > > Consider a GDB session with multiple inferiors. One inferior might be > a native target while another could be a remote target of a completely > different architecture. Alternatively, if we consider ARM and > AArch64, one native inferior might be AArch64, while a second native > inferior could be ARM. > > In these cases it is possible, and valid, for a user to have one > inferior selected, and place a breakpoint in the other inferior by > placing a breakpoint on a particular symbol. > > If this happens, then currently, when > gdbarch_adjust_breakpoint_address is called, the wrong inferior (and > program space) will be selected, and memory reads, and symbol look > ups, will not return the expected results, this could lead to > breakpoints being placed in the wrong location. > > There are currently two places where gdbarch_adjust_breakpoint_address > is called: > > 1. In infrun.c, in the function handle_step_into_function. In this > case, I believe that the correct inferior and program space will > already be selected as this is called as part of the stop event > handling, so I don't think we need to worry about this case, and > > 2. In breakpoint.c, in the function adjust_breakpoint_address, which > is itself called from code_breakpoint::add_location and > watch_command_1. > > The watch_command_1 case I don't think we need to worry about, this > is for when a local watch expression is created, which can only be > in the currently selected inferior, so this case should be fine. > > The code_breakpoint::add_location case is the one that needs fixing, > this is what allows a breakpoint to be created between inferiors. > > To fix the code_breakpoint::add_location case, I propose that we pass > the "correct" program_space (i.e. the program space in which the > breakpoint will be created) to the adjust_breakpoint_address function. > Then in adjust_breakpoint_address we can make use of > switch_to_program_space_and_thread to switch program_space and > inferior before calling gdbarch_adjust_breakpoint_address. > > I discovered this issue while working on a later patch in this > series. This later patch will detect when we cast the result of > gdbarch_tdep to the wrong type. > > With this later patch in place I ran gdb.multi/multi-arch.exp on an > AArch64 target. In this situation, two inferiors are created, an > AArch64 inferior, and an ARM inferior. The test selected the AArch64 > inferior and tries to create a breakpoint in the ARM inferior. > > As a result of this we end up in arm_adjust_breakpoint_address, which > calls arm_pc_is_thumb. Before this commit the AArch64 inferior would > be current. As a result, all of the checks in arm_pc_is_thumb would > fail (they rely on reading symbols from the current program space), > and so, at the end of arm_pc_is_thumb we would call > arm_frame_is_thumb. However, remember, at this point the current > inferior is the AArch64 inferior, so the current frame is an AArch64 > frame. > > In arm_frame_is_thumb we call arm_psr_thumb_bit, which calls > gdbarch_tdep and casts the result to arm_gdbarch_tdep. This is wrong, > the tdep field is of type aarch64_gdbarch_tdep. After this we have > undefined behaviour. > > With this patch in place, we will have switched to a thread in the ARM > program space before calling arm_adjust_breakpoint_address. As a > result, we now succeed in looking up the required symbols in > arm_pc_is_thumb, and so we never call arm_frame_is_thumb. > > However, in the worst case scenario, if we did end up calling > arm_frame_is_thumb, as the current inferior should now be the ARM > inferior, the current frame should be an ARM frame, so we still should > not hit undefined behaviour. > > I have added an assert to arm_frame_is_thumb. > --- > gdb/arm-tdep.c | 12 ++++++++---- > gdb/breakpoint.c | 24 ++++++++++++++++++------ > 2 files changed, 26 insertions(+), 10 deletions(-) > > diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c > index 7f27d4bd6e8..e0e5c7efd63 100644 > --- a/gdb/arm-tdep.c > +++ b/gdb/arm-tdep.c > @@ -541,20 +541,24 @@ arm_is_thumb (struct regcache *regcache) > return (cpsr & t_bit) != 0; > } > > -/* Determine if FRAME is executing in Thumb mode. */ > +/* Determine if FRAME is executing in Thumb mode. FRAME must be an ARM > + frame. */ > > int > arm_frame_is_thumb (struct frame_info *frame) > { > - CORE_ADDR cpsr; > - ULONGEST t_bit = arm_psr_thumb_bit (get_frame_arch (frame)); > + /* Check the architecture of FRAME. */ > + struct gdbarch *gdbarch = get_frame_arch (frame); > + gdb_assert (gdbarch_bfd_arch_info (target_gdbarch ())->arch == bfd_arch_arm); > > /* Every ARM frame unwinder can unwind the T bit of the CPSR, either > directly (from a signal frame or dummy frame) or by interpreting > the saved LR (from a prologue or DWARF frame). So consult it and > trust the unwinders. */ > - cpsr = get_frame_register_unsigned (frame, ARM_PS_REGNUM); > + CORE_ADDR cpsr = get_frame_register_unsigned (frame, ARM_PS_REGNUM); > > + /* Find and extract the thumb bit. */ > + ULONGEST t_bit = arm_psr_thumb_bit (gdbarch); > return (cpsr & t_bit) != 0; > } > > diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c > index ed932a19ed7..5370e70f15e 100644 > --- a/gdb/breakpoint.c > +++ b/gdb/breakpoint.c > @@ -124,7 +124,8 @@ static void breakpoint_adjustment_warning (CORE_ADDR, CORE_ADDR, int, int); > > static CORE_ADDR adjust_breakpoint_address (struct gdbarch *gdbarch, > CORE_ADDR bpaddr, > - enum bptype bptype); > + enum bptype bptype, > + struct program_space *pspace); > > static int watchpoint_locations_match (struct bp_location *loc1, > struct bp_location *loc2); > @@ -7114,8 +7115,11 @@ breakpoint_adjustment_warning (CORE_ADDR from_addr, CORE_ADDR to_addr, > > static CORE_ADDR > adjust_breakpoint_address (struct gdbarch *gdbarch, > - CORE_ADDR bpaddr, enum bptype bptype) > + CORE_ADDR bpaddr, enum bptype bptype, > + struct program_space *pspace) > { > + gdb_assert (pspace != nullptr); > + > if (bptype == bp_watchpoint > || bptype == bp_hardware_watchpoint > || bptype == bp_read_watchpoint > @@ -7140,10 +7144,16 @@ adjust_breakpoint_address (struct gdbarch *gdbarch, > { > CORE_ADDR adjusted_bpaddr = bpaddr; > > + /* Some targets have architectural constraints on the placement > + of breakpoint instructions. Obtain the adjusted address. */ > if (gdbarch_adjust_breakpoint_address_p (gdbarch)) > { > - /* Some targets have architectural constraints on the placement > - of breakpoint instructions. Obtain the adjusted address. */ > + /* Targets that implement this adjustment function will > + likely inspect either the symbol table, or target memory > + add BPADDR, so ensure a suitable thread (and its Is there something funny in the above line? Should add->and? Other than this, LGTM. Again, thanks for taking the time to address this.