From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2079.outbound.protection.outlook.com [40.107.20.79]) by sourceware.org (Postfix) with ESMTPS id 8C7A6392AC26 for ; Fri, 10 Jun 2022 16:29:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8C7A6392AC26 ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=h4CTXyzJjrl9DtoBbyzhgluEPXjcVxTtdOnIekDeB2r5+fhWm1TGYyauF6663/mtBedvNm58pvg6C6GJLsxb5H0+QECMt/MLU0DcQYI3o2L8ZZ+4oGGbK35VsoUeRmYECjxDjnv+fHRmT6ozekc8ZjDI/ClTJdPn0QldxTZcqIjIlBlcrv0pmcyrzxpQWIB5XVbG5TKhAeU5ERFp5T0zgT0Joesy5lS+H4E8zehxoux6ci6HcAudKdwwHGuUUVeXeFe21E66hT+nfiYT59qNtJ+zNG5blsgRFALWmWjbvTwnBZKVifa/kuX/vk11GcAwXDsmz7CiP6gqGmAWyYk9Gw== 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=JItH8aWuQ1wy8Abo+ACztNcyuGzvwtZB36i7TZWMuQM=; b=SZUti3nLLbDGjmU8UqHpbNLxPJWef+QxbHykjEdU66tSQNrQV4PyN+RLU1GsdiYejbfVPko+eR+fKwr+gzUNyHfJ8nJvBJDnSQBEsUTOSbhtCkx0kDHSTLn6d0RZ3pyHEx8trAeir/SPBrYan56Ne8rFojz/qHIJKL1KHPz3cd4335QiXcL/b6CEAf04uzOy0YuVCeVibThtreoctWbtsvpF8nmsWCGSHMS2ewwI/qDiZkgnGkWUuXuD2OH0HNBnPzh/IVksYQYbah8WrDX5eH1vbqxZwkQnXjO0hGINFFggFL7HhsgzL1wIPt6HNhrkjSBTJMA37pt1UMsadubIaA== 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 DB6PR07CA0101.eurprd07.prod.outlook.com (2603:10a6:6:2c::15) by HE1PR08MB2681.eurprd08.prod.outlook.com (2603:10a6:7:30::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5314.17; Fri, 10 Jun 2022 16:29:46 +0000 Received: from DBAEUR03FT040.eop-EUR03.prod.protection.outlook.com (2603:10a6:6:2c:cafe::12) by DB6PR07CA0101.outlook.office365.com (2603:10a6:6:2c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5353.6 via Frontend Transport; Fri, 10 Jun 2022 16:29:46 +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 DBAEUR03FT040.mail.protection.outlook.com (100.127.142.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5332.12 via Frontend Transport; Fri, 10 Jun 2022 16:29:46 +0000 Received: ("Tessian outbound 1766a3bff204:v120"); Fri, 10 Jun 2022 16:29:46 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 796874b627b4160e X-CR-MTA-TID: 64aa7808 Received: from 0b08524e31ca.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id FDB6672E-442A-4CE5-9BF4-058C54B48788.1; Fri, 10 Jun 2022 16:29:39 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 0b08524e31ca.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 10 Jun 2022 16:29:39 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Qn4PqZhIK9iA0te2r4RaOS7IpUAgWOYTOebVfWqcReKQMjQRyFrWxSiKrswZqCiC6xa/pWtT3l88ZlgVTGyfXeCFCiBSLOgGH2LTnulXlRj/e4soU2nX/bAjJoahYp6GLAYQ2f7lvV/pfQA4hvY8xpYbFi6dfN+0M3YTQG9pPEe1tUukfuG6yUkBm/EiJXPUQ90XQ05DLKZwOBNuEtprE9H3iXm0VleztmPr0/MmNS0fww2oQ7+hJU2GOGHiI33ZyFKkt8fnj2bapUDXQAT8WQoZm/xqZiUJJKiK37hYXuVjcNJg6/kExK4yeox+eZGLCkJL6jWJnV9jbQsKWIHlfw== 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=JItH8aWuQ1wy8Abo+ACztNcyuGzvwtZB36i7TZWMuQM=; b=eHWowDWZrYsY4P0v6j5FAaNtCjyqtYys1Xk7IjN3EsLkRFlo/I8RXG/5o1a/YFjadsTdmOp2P6EFqHulN3oNWztOrj+mEQHVkb4xehZQ54zHoEiiRv68Flwb7sFqmDyhlgabrwulcZtic1G7jtDY+fp9M8YLvJdO61YsxIg14e5cTpqbl/ag6DlU6kXwz9m2CZ53Px8q81qyUbxsXmdNQ6m+ULMykgckxCnZxDDhCbjPW9WbeZU4f1ohQlar0EqsaXSjM9/l7bzU5n9aDxKm5JsCpl68MvjNoFwUugESukh86bLljmF5ugDKzZH/XXb1h9INYx+nc0+umW6FrmCQGg== 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 AM6PR08MB4424.eurprd08.prod.outlook.com (2603:10a6:20b:73::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5332.13; Fri, 10 Jun 2022 16:29:37 +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.014; Fri, 10 Jun 2022 16:29:37 +0000 Message-ID: Date: Fri, 10 Jun 2022 17:29:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCHv2 3/6] gdb/arm: avoid undefined behaviour in arm_frame_is_thumb Content-Language: en-US To: Andrew Burgess , gdb-patches@sourceware.org References: <0d968da223ab233af5ce95520f5472a4d849d269.1654866187.git.aburgess@redhat.com> <87zgikecwo.fsf@redhat.com> From: Luis Machado In-Reply-To: <87zgikecwo.fsf@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO2P265CA0247.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:8a::19) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 141e4ba1-ce21-4c18-4f27-08da4afe6e85 X-MS-TrafficTypeDiagnostic: AM6PR08MB4424:EE_|DBAEUR03FT040:EE_|HE1PR08MB2681: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: MIc/HCgkFk7nf6nuOn2+37v3qgwHzvDj6i1j1ZbE/5OMBEQ2UYyMhh9JUXVIPTJccxbThvQLVChuf14k6jAHEV7DKOyhvotV79c2C7hs1hfAxk8z7Asbkk6gVODPnCzLVqdt1p6ELAhHDfpl+rSERjfIgUiWtJ94jjmcjWsBNNAe4KF7VIMFNrDJuLwE5bf9b+d9mtIDydGHwCB4mXEdldmmFTnis/gDMQUHwCnSbsmxbBxLYNU9mdY+8WgMTLV68Xl16Y4nd+rwvjVfesVkdCaBLKOeuVzQOlaRqNY4ZWXGXGin5TeX1r4zG91R3p3rgGiOMwx0q3uzsO/NWDPP4mkJ+PTaA8Yaadr+0hb1FzHgDq2Uml0vVBKKSAotJD57xs/ePRSEztY/tMihJTpRWauJT8Qhx0vhu5MISWNb6p0GrreeauRIUlK0UCxRBSUq5ngIp9LrBu7NflV5NLzZvUTTZeOhWLWmeJIx1xxEe7hUR+v8jTiNlOLFx2V5DgHZrVkb92BqJXaNihxUKhtmRRbnEw1QYrU73sBrhs7RGT34/VDULJnJrBRSRuI4SSM1/IShlnfkQ0ietzMU3ghz0TNwKhxKDetgS3ZlKJSBR3Un8tOlLEJM9f2mRriqcy3xnLgdyRskI0a1/T5YGo0UDMWSBDS2KU1kD1kks6mtZDplsLQKSnGnK/8Vy58KQ9oMhfzBbBA9OrCr0Xw+gUyRxCFaGDkYe/Cy2aCAlhtW+USJ+XMOeRvhK9lPzAFlavgWVxkfKM01losdlQwy22fXutrrzS4S51KC77X7Lo10UfV9cKuRfTV+zi4+EMML/Ve3 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:(13230001)(4636009)(366004)(316002)(83380400001)(66946007)(66556008)(66476007)(2906002)(6486002)(8676002)(5660300002)(44832011)(84970400001)(36756003)(6666004)(26005)(31696002)(53546011)(6506007)(6512007)(86362001)(31686004)(508600001)(2616005)(186003)(38100700002)(8936002)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4424 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: DBAEUR03FT040.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 1915bfef-7a8e-4fd7-ac10-08da4afe6936 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: IF8sUOFebKkmTBbBGvPtXEwSt4KZO2DFynZAvIlhUuHfRSPn9Nag6nf1lTWWyUCQHTPt2uc6swML+Elg7hOa8YtZT+CR5Zux6gNwQsCwQudEa5XIRtOe6PJYHctLsV7EAguZRRKa3dxG/YNqojGxYaM2XJnyGNfj9DIfToNAjpvjnbcjICj8hA80t6BVhfFTd4PagE+olPip7JyBGMpBdfwGFnoetU5wbNvS3Ku9ghdh6FhI79gyniC6Vlit7jxJBZm/VbJSnwrA7fg5eFRoCzTLbC2Pvz6RpgSPFDOa3u24K61cGhhUy7dciYInuwkHGC3J1Seh6y+2J7YYM9kIfngp4AJV83ndkuCfZf3f000j3KjgiCGVhfj6HZQ8tQWUFbwqmsRlCIePCeg2vo5hKBwQs2lDlREy9rbX1IOsXyFS9rF/3ZOruJFfKKNzqayV8Yp1Hud4s8nXGLl6jYfnYlskEpEAZaYvdSJiMNHIEuxOyOvhAxCGKvBR7Sm2KmelSMW1bQhHNNe3RAFpjspx+4zC8KFsSoFzJ0EjpTzpmZdrttXg20rE7ZGriMIWGegLbozBK3bIx+t2d+2zK7qkCWGN3vOZeiZ0+MIqSxqm/r+EV47mr3S9iGjmZQO6uts1lCZJT8ryCy2fCpume8i3AxQfLPsoPy89/KBn7LEfODwnEfOo8hOciIulgyNoZN3yHNRAwodBoLECThhSj8bYp+FWsX3vpJKIdVLVfAzv/B7G/+jD1IWOwIW+mZ+xvJa9unbXlyW1qf2Xo2g6di/aLBKNKCZFHZE9hO2mJaZtM1M= 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:(13230001)(4636009)(46966006)(36840700001)(40470700004)(36860700001)(508600001)(82310400005)(6506007)(6486002)(2906002)(316002)(53546011)(26005)(8676002)(44832011)(5660300002)(6666004)(40460700003)(356005)(70206006)(84970400001)(8936002)(70586007)(6512007)(47076005)(31686004)(336012)(83380400001)(2616005)(86362001)(36756003)(186003)(31696002)(81166007)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jun 2022 16:29:46.2569 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 141e4ba1-ce21-4c18-4f27-08da4afe6e85 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: DBAEUR03FT040.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR08MB2681 X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, FORGED_SPF_HELO, 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, WEIRD_PORT 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: Fri, 10 Jun 2022 16:29:56 -0000 On 6/10/22 16:49, Andrew Burgess wrote: > Luis Machado via Gdb-patches writes: > >> On 6/10/22 14:08, Andrew Burgess via Gdb-patches wrote: >>> This commit fixes real undefined behaviour in GDB which I spotted when >>> working on a later patch in this series. The later patch in this >>> series detects when the result of gdbarch_tdep() is cast to the wrong >>> type. >>> >>> The issue is revealed by the gdb.multi/multi-arch.exp test. >>> >>> In this test we setup two inferiors, an AArch64 process, and an ARM >>> process, then at one point we have inferior 1 selected (the AArch64 >>> inferior), and we place a breakpoint on a symbol present in the other >>> inferior (the ARM inferior). >>> >>> During the process of creating the breakpoint we call arm_pc_is_thumb, >>> the GDBARCH passed into this function is correct, that is, represents >>> the ARM process. >>> >>> For whatever reason we are unable to figure out if the address in >>> question is thumb or not throughout most of arm_pc_is_thumb, and so we >>> get to this code at the end of the function: >>> >>> /* If we couldn't find any symbol, but we're talking to a running >>> target, then trust the current value of $cpsr. This lets >>> "display/i $pc" always show the correct mode (though if there is >>> a symbol table we will not reach here, so it still may not be >>> displayed in the mode it will be executed). */ >>> if (target_has_registers ()) >>> return arm_frame_is_thumb (get_current_frame ()); >>> >>> Which I guess is a last attempt to figure out the thumb status of an >>> address. However, remember, we the AArch64 inferior is current at >>> this time, so the current frame is an AArch64 frame. >> >> If we're trying to insert a breakpoint into a 32-bit inferior, >> we should really have the 32-bit arm gdbarch at hand, not the AArch64 >> gdbarch. > > We do. > >> >> I think the bug is somewhere else, in whoever passed the current inferior's gdbarch >> as opposed to the gdbarch of the inferior that contains the symbol >> we've found. > > We do pass in the gdbarch of the inferior containing the breakpoint location. > > If I change the condition to an assert, then run > gdb.multi/multi-arch.exp and catch the assertion, the stack looks like > this: > > #0 internal_error (file=0x55834840c8 "../../src/gdb/arm-tdep.c", line=551, > fmt=0x5583483d70 "%s: Assertion `%s' failed.") at ../../src/gdbsupport/errors.cc:51 > #1 0x0000005582b0e6a4 in arm_frame_is_thumb (frame=0x55c0849a00) at ../../src/gdb/arm-tdep.c:551 > #2 0x0000005582b0eb70 in arm_pc_is_thumb (gdbarch=0x55c0937080, memaddr=4195692) at ../../src/gdb/arm-tdep.c:687 > #3 0x0000005582b17e70 in arm_adjust_breakpoint_address (gdbarch=0x55c0937080, bpaddr=4195692) > at ../../src/gdb/arm-tdep.c:4925 > #4 0x0000005582af0a60 in gdbarch_adjust_breakpoint_address (gdbarch=0x55c0937080, bpaddr=4195692) > at ../../src/gdb/gdbarch.c:2840 > #5 0x0000005582b73c90 in adjust_breakpoint_address (gdbarch=0x55c0937080, bpaddr=4195692, bptype=bp_breakpoint) > at ../../src/gdb/breakpoint.c:7147 > #6 0x0000005582b76854 in code_breakpoint::add_location (this=0x55c088e340, sal=...) > at ../../src/gdb/breakpoint.c:8100 > #7 0x0000005582b773b8 in code_breakpoint::code_breakpoint (this=0x55c088e340, gdbarch_=0x55c089c050, > type_=bp_breakpoint, sals=..., location_=..., filter_=std::unique_ptr = {...}, > cond_string_=std::unique_ptr = {...}, extra_string_=std::unique_ptr = {...}, > disposition_=disp_donttouch, thread_=-1, task_=0, ignore_count_=0, from_tty=1, enabled_=1, flags=0, > display_canonical_=0) at ../../src/gdb/breakpoint.c:8329 > #8 0x0000005582b90c00 in ordinary_breakpoint::code_breakpoint (this=0x55c088e340) at ../../src/gdb/breakpoint.c:266 > #9 0x0000005582b88758 in new_breakpoint_from_type&, std::unique_ptr, std::unique_ptr >, std::unique_ptr >, std::unique_ptr >, bpdisp&, int&, int&, int&, int&, int&, unsigned int&, int&> (gdbarch=0x55c089c050, type=bp_breakpoint) at ../../src/gdb/breakpoint.c:1303 > #10 0x0000005582b77710 in create_breakpoint_sal (gdbarch=0x55c089c050, sals=..., location=..., > filter=std::unique_ptr = {...}, cond_string=std::unique_ptr = {...}, > extra_string=std::unique_ptr = {...}, type=bp_breakpoint, disposition=disp_donttouch, thread=-1, task=0, > ignore_count=0, from_tty=1, enabled=1, internal=0, flags=0, display_canonical=0) > at ../../src/gdb/breakpoint.c:8395 > #11 0x0000005582b779d8 in create_breakpoints_sal (gdbarch=0x55c089c050, canonical=0x7fd8d196c0, > cond_string=std::unique_ptr = {...}, extra_string=std::unique_ptr = {...}, type=bp_breakpoint, > disposition=disp_donttouch, thread=-1, task=0, ignore_count=0, from_tty=1, enabled=1, internal=0, flags=0) > at ../../src/gdb/breakpoint.c:8438 > #12 0x0000005582b78d94 in create_breakpoint (gdbarch=0x55c089c050, location=0x55c0979750, cond_string=0x0, thread=-1, > extra_string=0x0, force_condition=false, parse_extra=1, tempflag=0, type_wanted=bp_breakpoint, ignore_count=0, > pending_break_support=AUTO_BOOLEAN_AUTO, ops=0x558389c650 , from_tty=1, enabled=1, > internal=0, flags=0) at ../../src/gdb/breakpoint.c:8923 > #13 0x0000005582b792d8 in break_command_1 (arg=0x55c0732fc2 "", flag=0, from_tty=1) at ../../src/gdb/breakpoint.c:8994 > #14 0x0000005582b79578 in break_command (arg=0x55c0732fb6 "hangout_loop", from_tty=1) > at ../../src/gdb/breakpoint.c:9065 > > In frame #6 we select a gdbarch based on the location of the breakpoint, > its at this point that we select the bfd_arch_arm gdbarch. > > For frames #5, #4, #3, and #2 we are passing in a bfd_arch_arm gdbarch, > which is correct, and what you are asking for. > > The problem is that in frame #2 we fail to find any of the special hints > that indicate if the code is thumb or not. Now, _maybe_ you could argue > that one of the conditions in arm_pc_is_thumb should trigger, but, for > me, the very fact that there is a "catch all" case at the end of the > function means we have to be open to the possibility that non of the > special symbols, or bottom bit of the address set cases might trigger. > > And so, we get to this code in arm_pc_is_thumb: > > if (target_has_registers ()) > return arm_frame_is_thumb (get_current_frame ()); Thanks for the above backtrace, that was very helpful. Yeah, this call is making the wrong assumption that the current frame is arm. This is clearly not always valid on a multi-arch scenario. > > At this point GDBARCH _is_ a bfd_arch_arm architecture. > > But, the current frame is bfd_arch_aarch64. > > And so, we enter frame #1, arm_frame_is_thumb, passing in a frame that > is not bfd_arch_arm. > > So, are you are suggesting we should switch frames as part of the > breakpoint setting process? Because I'm not sure how you'd pick even a > suitable inferior, multiple ARM inferiors might share a single program > space, so we could have a single gdbarch, but multiple inferiors, each > with multiple threads, and each thread with multiple frames... > The correct way to do it is to fetch the frame from the inferior containing the breakpoint location, but you're right that there isn't a good way to do it here. Ideally GDB would keep per-inferior frame data, but it doesn't. This looks like a limitation of GDB. If you have the same bfd for all inferiors, I suppose you could get away with it. In this case though, trying to use the aarch64 bfd to do an operation for the arm bfd is not going to work. > I guess we could push the architecture check out of arm_frame_is_thumb > back to arm_pc_is_thumb, and only call arm_frame_is_thumb for the case > where the architecture is ARM... that doesn't make sense to me, but > maybe, I guess... It also doesn't make sense, because then the answer to whether we have thumb or not is always going to be false for an aarch64 bfd. We might as well return false and not fetch the frame. > > Anyway, let me know if the above makes any more sense. If it does I can > update the commit message Given this is broken either way, let's go with your patch. But could you please add a comment in the bfd check stating this is currently incorrect because fetching the current_frame doesn't reflect the correct inferior? I'll take a look at this later, but I don't want to block your series.