From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50050.outbound.protection.outlook.com [40.107.5.50]) by sourceware.org (Postfix) with ESMTPS id A2C3B3852764 for ; Fri, 10 Jun 2022 16:31:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A2C3B3852764 ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=iotF+I3Z5kGRbLJBx250B1Uvh4nWlMSd/WwgG9DKU81wsJkJw29/X1MCmsedcK3dcy+VaYypfK0nRmUxHmJi/HEggycgatAquqkONeVxGbr+46Yl/XwLcuHnCk4fB5BBfek7Sh8j21L/UPr0TnqbcDhJANPRXYhK4SuexvhmWdGGhLN4ZnSZ+IxOfGf4oN7g3wg/gF/KwFOGTsnERIAKIudrdf0eGWsEyMUAXxIgAhvVkdoa18BDNYhJeAI1zSe53Z6GnPdnRiDpPNx0mSAgl1QevgRsj2/1RDcGZFdOk4gSJkOhmYiUyQQwIDFk4NYOlHJX2SCJmfgnaip2DNRcVQ== 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=VIHePRELV1fR0qPsH00D/NYyu617PVhp+I4iYra/grY=; b=alEyp1FyHSx6AesH3ZxEwWIsjv5zhirQ/TrBc0wL6/OvRKWzEVHIL07Up9x1kb1y0/tkTBcimEag7onTR1yM1OODOVykCwXm+BUZZtY/3qCxStWKnxvWQnRLzSKLz0t2NhcC9Nv5Ea285H7Em5vEADsughg8zkp+ZeR3xuhWBkP1OEY3Qg+MMuXqhJJWQqSI+KmAIeBQOVb2aA7htVyTRqWe+qaeQ4oqixjvk+oYPda32OB8xz8Qn2P7txAUx+ePYTJ0WFoQdON9H1OP+er3C1leYnB8n45f5AhHVGhD57uW7fKpEt/lxuyw7O567/EJGtyce52KXm/CsM9tufHxsw== 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 AS9PR0301CA0054.eurprd03.prod.outlook.com (2603:10a6:20b:469::12) by VI1PR08MB5534.eurprd08.prod.outlook.com (2603:10a6:803:135::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5332.12; Fri, 10 Jun 2022 16:31:47 +0000 Received: from AM5EUR03FT009.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:469:cafe::7e) by AS9PR0301CA0054.outlook.office365.com (2603:10a6:20b:469::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5332.15 via Frontend Transport; Fri, 10 Jun 2022 16:31:47 +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 AM5EUR03FT009.mail.protection.outlook.com (10.152.16.110) 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:31:47 +0000 Received: ("Tessian outbound ff2e13d26e0f:v120"); Fri, 10 Jun 2022 16:31:47 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 16ebd5e035ebd115 X-CR-MTA-TID: 64aa7808 Received: from 976fd9c810ac.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 8953F237-8733-41A5-BBD8-399483E380D9.1; Fri, 10 Jun 2022 16:31:40 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 976fd9c810ac.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 10 Jun 2022 16:31:40 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fEfBs/UyLjkanyzEOXFgTlG1s4qucz12a2jyeiX+CoQChklDlDDRCWKri7oKFFv9c7/lGDi0Ct8MYyzhSTAZJS4eqxser4LlIR0XxOUGUJXDkOQh2XsLN1IDL4E0ibkqVybde+M8Sl99pB2nXGvlbHuuk6F3rt47Qm8K4pMKEGyyHj32LRGP7dOfPCYicBoM2SlyqW6LYWIadl1dvcHP4GUUYGqKgMt1dYRiaVNaqX04DE5t7iZKu5FC80FRkjkzJSPkEpkAT5Va2SLz/lViBjs0oOPtBUl/Y/DwwiKIF11g7brsehqvAKrGhU9Hy35x1nepHqW0aq+m/2Fr3wq4LQ== 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=VIHePRELV1fR0qPsH00D/NYyu617PVhp+I4iYra/grY=; b=iS7+GOVnrqlKoZ890fsolKga7SNYZuO57RJrhbn5S44tgojMWiuun+Aue/+AMQt36QNXRudaVpcy5GLPEOf2rjC5aenN9Occx+iAAT2aUEkcpjbj3Scxi3SPX+1n786MKbtmkTRe2A175JIsjSO3M1rEwwcw+8e5MMB81Osd/ANgHelPjDGcWDfrbMZyIsHmqMVHdZsfoVVU/E5D10w2ESE0V9SJmdGh+4dmaBL72x3F9W75Hq3ArIrtdxS8biHds5gAZh6sbdfVTTDhM/EgYgVAXyOe0sqW1mp6s0UcJAjIuMLW9HappNgRvB76CAHG+EwNlKYiaX32zP8tsqDdXg== 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:31:38 +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:31:38 +0000 Message-ID: <08eb614e-0f32-c4f3-17fb-a0e853b0c9ba@arm.com> Date: Fri, 10 Jun 2022 17:31:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCHv2 6/6] gdb: native target invalid architecture detection Content-Language: en-US To: Andrew Burgess , gdb-patches@sourceware.org References: <644591dc859ea741999f73aaa28a1bffa83ceab5.1654866188.git.aburgess@redhat.com> From: Luis Machado In-Reply-To: <644591dc859ea741999f73aaa28a1bffa83ceab5.1654866188.git.aburgess@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0154.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:188::15) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: c4cf321c-bcff-4d37-04d4-08da4afeb6cb X-MS-TrafficTypeDiagnostic: AM6PR08MB4424:EE_|AM5EUR03FT009:EE_|VI1PR08MB5534: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: wm4flFlwYJRA7qPQhqb0vJ0ZTfZ0S78DztIJzt7AVFIPeCjtRR8GuWG4jAc+iyOfh0Cg/4i2exTKlFAhLMdv/1c+e1R864pGYFDEwk3VMd3r6YMaKv9FyUGhwNdb9FyvsZmLrYA33I21zSKuSHkRm5iNsY7s2s9TOybMtwNQiJ5HrZxbhzi/7nCN8QZwIyf82CjxHuYroaYTcpd87RbYzIO8PQIqFrkqAS6fh8p2gE5LXgQ0T8eMw6xnBTRKtLTsIMP/zRigSBKcyN2uE4niz9jQYyhgcDIrQXY068aLA4smBe2WabXiEh7tfjmDAG+0zWxiwvTkx3gSlfnzxj+I5VORqBjwUx0SE3xZY5LSALDTIuhg1ladqc9HMd+IapVNoqOA7V9gIi8YmGGE7ala6ADsQKBE3AlCZbksOgRFLHLgWkgcl2BzABXt5TlBEbOGoVosdcyL0VOrxHwAUij+7mCsM9CRDIBHzzlHbIYR7aYSK4EspJlHEq3F3AAmTEuXzyMLFkzZt7kIFSuBp3tvTR/ZY/mrgPXV05C4h5tOJZwfYEL1mhZwIDsXTlHiYAgoUBmUd8WMykjFNBl8W/RX4QwBtmMEKcoPUIa12S8dXeIWMR9iS5mSnMKLnYYsNBTimzZesnVE4s+o7M6doZihRnQblFjGXS1rY1y9xBLxJTtZzWrJGRcnckVMMs/rIMvwsB9SWGTGJad1BH2Qz+6q4ejjidXYYE0IaDp20Sf/EpoE5R7ArCLZAUd35RfpHouOThsuyhSDMzVQXh7x5N1q382FnmXUzLp387DQTGW8fVxFnaqN457uOo4lF3FMIeCAyQqfzAVvCINrgT7MPvdOTg== 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)(30864003)(44832011)(84970400001)(36756003)(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: AM5EUR03FT009.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 52e1b5b3-561f-4b71-a6fb-08da4afeb111 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: yrrsxJuKOXEi2LIfPnvJj6FjEfgZw4sxcpIZ2emFEcAWorN5ldaRwg0Eg5oLvK0fepi0csEKDaQQ5+m4YAETc8/hBld3a/uDSMkttDmAowxBMWrq+nLs1Ig2A1fAOc8TDvNZMRqyYXRn6gas8jdsCyOlQPz6qgZVx6X2F4CaJXYwABSewmhouhUQ1JnXqXFa9HPURPZH0voqJVjWGNJ616mg0TVbMM9WBze+I93pTZqtz+m4GOQ9G1v68gTxf/LdhtqG4qeSUf8LUcrzjYcxrg5dOoAVXZ3k2kSnGCcqu3t4QT4sWOLf5m7GYRKTC69qHoCu2FUBEFMHN9HwsPwPHOITx9y6gjhjKg7lJQDXfL2jH0U3tnfEtEi2IDqdkzuW7Yep5BOMNleb6Za3cPV2uKPrsUTWRUuthIt4kQKwfUGzl+bq2yWN0ec/uwSFKcd6TPlS+2R+lTr76AM+QrvQPbLOKE9SpEnxv89xXDrEzkn6IKH9gUhZgnNEhgEdmnW7FbtFKSYoMSA36wmuQ6+AYjht7qrgvc2NSQndXn2jGlICZCM+fXsw614ypkthIqEaaXlRkZ9rr5NOyXx50XwA7zZdwNWCcdlzNjzDHQPCCVygqyO3CWyekezL03NILvUarFacaP8Ek3DiIeyGH0x6a5WA5JlDkjZfiZL4DEfz7pZ8zV6YiOR9BBIjAEEJFS2EaQZL3xTOTNP+BZ1f7BaUUcoMMBMAzEqg+QDIKWYk4E7dL4Jgzok/9onaJ0/cfUiraNtYL/JSSjoQwbJROQMo6J+Pz4AC3gKBaPXOVCem3MY= 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)(36840700001)(40470700004)(46966006)(30864003)(8676002)(44832011)(5660300002)(47076005)(186003)(36860700001)(36756003)(70586007)(82310400005)(316002)(70206006)(83380400001)(336012)(6486002)(508600001)(31686004)(2906002)(40460700003)(84970400001)(6506007)(53546011)(2616005)(86362001)(81166007)(31696002)(8936002)(26005)(6512007)(356005)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jun 2022 16:31:47.4316 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c4cf321c-bcff-4d37-04d4-08da4afeb6cb 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: AM5EUR03FT009.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB5534 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: Fri, 10 Jun 2022 16:31:54 -0000 On 6/10/22 14:08, Andrew Burgess via Gdb-patches wrote: > If GDB is asked to start a new inferior, or attach to an existing > process, using a binary file for an architecture that does not match > the current native target, then, currently, GDB will assert. Here's > an example session using current HEAD of master with GDB built for an > x86-64 GNU/Linux native target, the binary being used is a RISC-V ELF: > > $ ./gdb/gdb -q --data-directory ./gdb/data-directory/ > (gdb) file /tmp/hello.rv32imc.x > Reading symbols from /tmp/hello.rv32imc.x... > (gdb) start > Temporary breakpoint 1 at 0x101b2: file hello.rv32.c, line 23. > Starting program: /tmp/hello.rv32imc.x > ../../src/gdb/gdbarch.h:166: internal-error: gdbarch_tdep: Assertion `dynamic_cast (tdep) != nullptr' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > > The same error is encountered if, instead of starting a new inferior, > the user tries to attach to an x86-64 process with a RISC-V binary set > as the current executable. > > These errors are not specific to the x86-64/RISC-V pairing I'm using > here, any attempt to use a binary for one architecture with a native > target of a different architecture will result in a similar error. > > Clearly, attempting to use this cross-architecture combination is a > user error, but I think GDB should do better than an assert; ideally a > nice error should be printed. > > The problem we run into is that, when the user starts a new inferior, > or attaches to an inferior, the inferior stops. At this point GDB > attempts to handle the stop, and this involves reading registers from > the inferior. > > These register reads end up being done through the native target, so > in the example above, we end up in the amd64_supply_fxsave function. > However, these functions need a gdbarch. The gdbarch is fetched from > the register set, which was constructed using the gdbarch from the > binary currently in use. And so we end up in amd64_supply_fxsave > using a RISC-V gdbarch. > > When we call: > > i386_gdbarch_tdep *tdep = gdbarch_tdep (gdbarch); > > this will assert as the gdbarch_tdep data within the RISC-V gdbarch is > of the type riscv_gdbarch_tdep not i386_gdbarch_tdep. > > The solution I propose in this commit is to add a new target_ops > method supports_architecture_p. This method will return true if a > target can safely be used with a specific architecture, otherwise, the > method returns false. > > I imagine that a result of true from this method doesn't guarantee > that GDB can start an inferior of a given architecture, it just means > that GDB will not crash if such an attempt is made. A result of false > is a hard stop; attempting to use this target with this architecture > is not supported, and may cause GDB to crash. > > This distinction is important I think for things like remote targets, > and possibly simulator targets. We might imagine that GDB can ask a > remote (or simulator) to start with a particular executable, and the > target might still refuse for some reason. But my thinking is that > these refusals should be well handled (i.e. GDB should give a user > friendly error), rather than crashing, as is the case with the native > targets. > > For example, if I start gdbserver on an x86-64 machine like this: > > gdbserver --multi :54321 > > Then use GDB to try and load a RISC-V binary, like this: > > $ ./gdb/gdb -q --data-directory ./gdb/data-directory/ > (gdb) file /tmp/hello.rv32imc.x > Reading symbols from /tmp/hello.rv32imc.x... > (gdb) target extended-remote :54321 > Remote debugging using :54321 > (gdb) run > Starting program: /tmp/hello.rv32imc.x > Running the default executable on the remote target failed; try "set remote exec-file"? > (gdb) > > Though the error is not very helpful in diagnosing the problem, we can > see that GDB has not crashed, but has given the user an error. > > And so, the supports_architecture_p method is created to return true > by default, then I override this in inf_child_target, where I compare > the architecture in question with the default_bfd_arch. > > Finally, I've added calls to supports_architecture_p for the > run (which covers run, start, starti) and attach commands. > > This leaves just one question, what about native targets that support > multiple architectures? > > These targets can be split into two groups. First, we have targets > like x86-64, which also supports i386 binaries. This case is easy to > handle, as far as BFD is concerned there is only one architecture, > bfd_arch_i386, and we then use machine types to split this > architecture into x86-64 and i386 (and others). As the new > supports_architecture_p function only checks the bfd architecture, > then there is nothing additional needed for this case. > > The second group of multi-architecture targets requires more work. > The only targets that I'm aware of that fall into this group are the > rs6000-aix-nat.c, ppc-*-nat.c targets, and the aarch64-linux-nat.c > target. > > The first group (rs600/ppc) support bfd_arch_rs6000 and > bfd_arch_powerpc, while the second (aarch64) supports bfd_arch_arm and > bfd_arch_aarch64. > > To deal with these targets I have overridden the > supports_architecture_p function in each of the separate target files, > these overrides check both of the supported architectures. > > One final note, in the rs6000/ppc case, the FreeBSD target supports > both architectures, and so we override supports_architecture_p. In > contrast, the aarch64_fbsd_nat_target target does not (yet) support > bfd_arch_arm, and so there is no supports_architecture_p here. This > can always be added later if/when support is added. > > You will notice a lack of tests for this change. I'm not sure of a > good way that I can build a binary for a different architecture as > part of a test, but if anyone has any ideas then I'll be happy to add > a test here. The gdb.base/multi-arch.exp test exists, which for > AArch64 will test compiling and running something as both AArch64 and > ARM, but this doesn't cover the error case, just that the overridden > supports_architecture_p works in that case. > --- > gdb/aarch64-linux-nat.c | 8 ++++++++ > gdb/arch-utils.c | 8 ++++++++ > gdb/arch-utils.h | 5 +++++ > gdb/inf-child.c | 19 +++++++++++++++++++ > gdb/inf-child.h | 2 ++ > gdb/infcmd.c | 8 ++++++++ > gdb/ppc-fbsd-nat.c | 8 ++++++++ > gdb/ppc-linux-nat.c | 8 ++++++++ > gdb/ppc-obsd-nat.c | 8 ++++++++ > gdb/rs6000-aix-nat.c | 8 ++++++++ > gdb/target-delegates.c | 28 ++++++++++++++++++++++++++++ > gdb/target.h | 13 ++++++++++++- > 12 files changed, 122 insertions(+), 1 deletion(-) > > diff --git a/gdb/aarch64-linux-nat.c b/gdb/aarch64-linux-nat.c > index a457fcd48ad..6114c4c6638 100644 > --- a/gdb/aarch64-linux-nat.c > +++ b/gdb/aarch64-linux-nat.c > @@ -108,6 +108,14 @@ class aarch64_linux_nat_target final > /* Write allocation tags to memory via PTRACE. */ > bool store_memtags (CORE_ADDR address, size_t len, > const gdb::byte_vector &tags, int type) override; > + > + /* This target supports two architectures, check for them both here. */ > + > + bool supports_architecture_p (struct gdbarch *gdbarch) override > + { > + bfd_architecture the_arch = gdbarch_bfd_arch_info (gdbarch)->arch; > + return (the_arch == bfd_arch_aarch64 || the_arch == bfd_arch_arm); > + } > }; > > static aarch64_linux_nat_target the_aarch64_linux_nat_target; > diff --git a/gdb/arch-utils.c b/gdb/arch-utils.c > index 360b8d694be..efba17e1d5d 100644 > --- a/gdb/arch-utils.c > +++ b/gdb/arch-utils.c > @@ -1570,6 +1570,14 @@ target_gdbarch (void) > return current_inferior ()->gdbarch; > } > > +/* See arch-utils.h. */ > + > +bool > +gdbarch_matches_default_arch (struct gdbarch *gdbarch) > +{ > + return gdbarch_bfd_arch_info (gdbarch)->arch == default_bfd_arch->arch; > +} > + > void _initialize_gdbarch_utils (); > void > _initialize_gdbarch_utils () > diff --git a/gdb/arch-utils.h b/gdb/arch-utils.h > index f850e5fd6e7..5d61be36c26 100644 > --- a/gdb/arch-utils.h > +++ b/gdb/arch-utils.h > @@ -300,4 +300,9 @@ extern void default_read_core_file_mappings > struct bfd *cbfd, > read_core_file_mappings_pre_loop_ftype pre_loop_cb, > read_core_file_mappings_loop_ftype loop_cb); > + > +/* Return true if the bfd architecture of GDBARCH matches the default bfd > + architecture. */ > + > +extern bool gdbarch_matches_default_arch (struct gdbarch *gdbarch); > #endif /* ARCH_UTILS_H */ > diff --git a/gdb/inf-child.c b/gdb/inf-child.c > index 56ebd2a5549..0c47a367c68 100644 > --- a/gdb/inf-child.c > +++ b/gdb/inf-child.c > @@ -30,6 +30,8 @@ > #include "inferior.h" > #include > #include "inf-child.h" > +#include "gdbarch.h" > +#include "arch-utils.h" > #include "gdbsupport/fileio.h" > #include "gdbsupport/agent.h" > #include "gdbsupport/gdb_wait.h" > @@ -412,6 +414,23 @@ inf_child_target::follow_exec (inferior *follow_inf, ptid_t ptid, > } > } > > +/* The inf_child_target represents the native target built into GDB, of > + which there is only ever one. If we attempt to start a native inferior > + using a binary for an architecture not matching the native target then, > + when we handle the first stop, we will end up trying to read registers > + using the gdbarch functions from the native target, but passing in a > + gdbarch object based on the architecture of the binary file. This will > + result in errors. > + > + This check prevents this so long as everywhere user command that might > + cause a new inferior to be created calls this function. */ > + > +bool > +inf_child_target::supports_architecture_p (struct gdbarch *gdbarch) > +{ > + return gdbarch_matches_default_arch (gdbarch); > +} > + > /* See inf-child.h. */ > > void > diff --git a/gdb/inf-child.h b/gdb/inf-child.h > index ae5ace46f30..01a8164b0c2 100644 > --- a/gdb/inf-child.h > +++ b/gdb/inf-child.h > @@ -92,6 +92,8 @@ class inf_child_target > > bool can_use_agent () override; > > + bool supports_architecture_p (struct gdbarch *gdbarch) override; > + > protected: > /* Unpush the target if it wasn't explicitly open with "target native" > and there are no live inferiors left. Note: if calling this as a > diff --git a/gdb/infcmd.c b/gdb/infcmd.c > index e909d4d4c81..b8acf858b3a 100644 > --- a/gdb/infcmd.c > +++ b/gdb/infcmd.c > @@ -413,6 +413,10 @@ run_command_1 (const char *args, int from_tty, enum run_how run_how) > if (non_stop && !run_target->supports_non_stop ()) > error (_("The target does not support running in non-stop mode.")); > > + if (!run_target->supports_architecture_p (get_current_arch ())) > + error (_("The target does not support architecture \"%s\"."), > + gdbarch_bfd_arch_info (get_current_arch ())->printable_name); > + > /* Done. Can now set breakpoints, change inferior args, etc. */ > > /* Insert temporary breakpoint in main function if requested. */ > @@ -2590,6 +2594,10 @@ attach_command (const char *args, int from_tty) > if (non_stop && !attach_target->supports_non_stop ()) > error (_("Cannot attach to this target in non-stop mode")); > > + if (!attach_target->supports_architecture_p (get_current_arch ())) > + error (_("The target does not support architecture \"%s\"."), > + gdbarch_bfd_arch_info (get_current_arch ())->printable_name); > + > attach_target->attach (args, from_tty); > /* to_attach should push the target, so after this point we > shouldn't refer to attach_target again. */ > diff --git a/gdb/ppc-fbsd-nat.c b/gdb/ppc-fbsd-nat.c > index d0a5778e2d3..f7c36c33958 100644 > --- a/gdb/ppc-fbsd-nat.c > +++ b/gdb/ppc-fbsd-nat.c > @@ -41,6 +41,14 @@ struct ppc_fbsd_nat_target final : public fbsd_nat_target > { > void fetch_registers (struct regcache *, int) override; > void store_registers (struct regcache *, int) override; > + > + /* This target supports two architectures, check for them both here. */ > + > + bool supports_architecture_p (struct gdbarch *gdbarch) override > + { > + bfd_architecture the_arch = gdbarch_bfd_arch_info (gdbarch)->arch; > + return (the_arch == bfd_arch_rs6000 || the_arch == bfd_arch_powerpc); > + } > }; > > static ppc_fbsd_nat_target the_ppc_fbsd_nat_target; > diff --git a/gdb/ppc-linux-nat.c b/gdb/ppc-linux-nat.c > index de4158c411a..e302b15925a 100644 > --- a/gdb/ppc-linux-nat.c > +++ b/gdb/ppc-linux-nat.c > @@ -551,6 +551,14 @@ struct ppc_linux_nat_target final : public linux_nat_target > > void low_prepare_to_resume (struct lwp_info *) override; > > + /* This target supports two architectures, check for them both here. */ > + > + bool supports_architecture_p (struct gdbarch *gdbarch) override > + { > + bfd_architecture the_arch = gdbarch_bfd_arch_info (gdbarch)->arch; > + return (the_arch == bfd_arch_rs6000 || the_arch == bfd_arch_powerpc); > + } > + > private: > > void copy_thread_dreg_state (const ptid_t &parent_ptid, > diff --git a/gdb/ppc-obsd-nat.c b/gdb/ppc-obsd-nat.c > index e480f19dc73..2fdccc3085d 100644 > --- a/gdb/ppc-obsd-nat.c > +++ b/gdb/ppc-obsd-nat.c > @@ -39,6 +39,14 @@ struct ppc_obsd_nat_target final : public obsd_nat_target > { > void fetch_registers (struct regcache *, int) override; > void store_registers (struct regcache *, int) override; > + > + /* This target supports two architectures, check for them both here. */ > + > + bool supports_architecture_p (struct gdbarch *gdbarch) override > + { > + bfd_architecture the_arch = gdbarch_bfd_arch_info (gdbarch)->arch; > + return (the_arch == bfd_arch_rs6000 || the_arch == bfd_arch_powerpc); > + } > }; > > static ppc_obsd_nat_target the_ppc_obsd_nat_target; > diff --git a/gdb/rs6000-aix-nat.c b/gdb/rs6000-aix-nat.c > index 8697d27b4ed..603caa8fb1e 100644 > --- a/gdb/rs6000-aix-nat.c > +++ b/gdb/rs6000-aix-nat.c > @@ -91,6 +91,14 @@ class rs6000_nat_target final : public inf_ptrace_target > > ptid_t wait (ptid_t, struct target_waitstatus *, target_wait_flags) override; > > + /* This target supports two architectures, check for them both here. */ > + > + bool supports_architecture_p (struct gdbarch *gdbarch) override > + { > + bfd_architecture the_arch = gdbarch_bfd_arch_info (gdbarch)->arch; > + return (the_arch == bfd_arch_rs6000 || the_arch == bfd_arch_powerpc); > + } > + > protected: > > void post_startup_inferior (ptid_t ptid) override > diff --git a/gdb/target-delegates.c b/gdb/target-delegates.c > index 8a9986454dd..cb7bb1f2062 100644 > --- a/gdb/target-delegates.c > +++ b/gdb/target-delegates.c > @@ -196,6 +196,7 @@ struct dummy_target : public target_ops > bool supports_memory_tagging () override; > bool fetch_memtags (CORE_ADDR arg0, size_t arg1, gdb::byte_vector &arg2, int arg3) override; > bool store_memtags (CORE_ADDR arg0, size_t arg1, const gdb::byte_vector &arg2, int arg3) override; > + bool supports_architecture_p (struct gdbarch *arg0) override; > }; > > struct debug_target : public target_ops > @@ -370,6 +371,7 @@ struct debug_target : public target_ops > bool supports_memory_tagging () override; > bool fetch_memtags (CORE_ADDR arg0, size_t arg1, gdb::byte_vector &arg2, int arg3) override; > bool store_memtags (CORE_ADDR arg0, size_t arg1, const gdb::byte_vector &arg2, int arg3) override; > + bool supports_architecture_p (struct gdbarch *arg0) override; > }; > > void > @@ -4536,3 +4538,29 @@ debug_target::store_memtags (CORE_ADDR arg0, size_t arg1, const gdb::byte_vector > return result; > } > > +bool > +target_ops::supports_architecture_p (struct gdbarch *arg0) > +{ > + return this->beneath ()->supports_architecture_p (arg0); > +} > + > +bool > +dummy_target::supports_architecture_p (struct gdbarch *arg0) > +{ > + return true; > +} > + > +bool > +debug_target::supports_architecture_p (struct gdbarch *arg0) > +{ > + bool result; > + gdb_printf (gdb_stdlog, "-> %s->supports_architecture_p (...)\n", this->beneath ()->shortname ()); > + result = this->beneath ()->supports_architecture_p (arg0); > + gdb_printf (gdb_stdlog, "<- %s->supports_architecture_p (", this->beneath ()->shortname ()); > + target_debug_print_struct_gdbarch_p (arg0); > + gdb_puts (") = ", gdb_stdlog); > + target_debug_print_bool (result); > + gdb_puts ("\n", gdb_stdlog); > + return result; > +} > + > diff --git a/gdb/target.h b/gdb/target.h > index 18559feef89..5f3ae77f559 100644 > --- a/gdb/target.h > +++ b/gdb/target.h > @@ -1320,7 +1320,18 @@ struct target_ops > virtual bool store_memtags (CORE_ADDR address, size_t len, > const gdb::byte_vector &tags, int type) > TARGET_DEFAULT_NORETURN (tcomplain ()); > - }; > + > + /* Return false if the target does not support GDBARCH, otherwise, > + return true. > + > + The default reply of true does not guarantee that debugging an > + inferior with architecture GDBARCH will succeed, other errors might > + be thrown later on, but a return value of false is a clear > + indication that we should not proceed attempting to use this > + architecture with this target. */ > + virtual bool supports_architecture_p (struct gdbarch *gdbarch) > + TARGET_DEFAULT_RETURN (true); > +}; > > /* Deleter for std::unique_ptr. See comments in > target_ops::~target_ops and target_ops::close about heap-allocated LGTM from aarch64's side.