From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10056.outbound.protection.outlook.com [40.107.1.56]) by sourceware.org (Postfix) with ESMTPS id 8A3CF3836E63 for ; Wed, 1 Jun 2022 08:26:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8A3CF3836E63 ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=dhby++8jfMkav9dSysbuud3bmBhmnypScx9JMH9wmjL+mRVFMBTsN1wJgnTESdsrVu1HFdOGwUlx8kooufASPPdK7E+qcljXo78ltIkIDTKgRnTvoQycQLg9RuFMEUnq48C0/dtuplXvh+kbFqQGY6bgVixb35A9urfMG60tKFKXtGzvh5bI4dpJLGwsEB2/sMV5Z0CDDrzDEx8/+k7+9UtcEixiG/mkLY2db8GpYXwwk6bPNpfqw5F6IAReRnhJM/INge6fAUC+9dsE2wCX3YNv+Wgwggwz25VAp4G8EUyaNOTvz2AKE1kae8yLt3UByBL/nHdfmZo8s26LAyL5Fw== 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=1NRn4XVc7WPWQ/ukCazCnu+4Y8GVDFe3bfaqTvc4R6g=; b=doVS2kRlrwPz0ZRFhF69BItFv8MPfZKdO16bKn3CARkSFaZ0DrUTTFWvtP4WyX5xYH5l+1XTIcpGdedd87JA7CtyQD3y2ucbOUW/yVk0Z3m37CB8adediXgeIy40xF3WLDH7qPprZi4+Dara8QtzHLqvUc9l9qUnLBxZlhBhcXASf9sQE/8dwktP8GanTvJwHWGfxNpSRQm6fEzDKgSUBnCQcGilHzkF+CrFJ/PCPxf+FA7V4PwRyu7nJq7XxzTURA0UbgJTL2SxxToMPNAiP+bH3V9fxDQFlwBr2pJ2+AbTEdO8wfO9fH9IvHXYVdxtnfQYDlp7GCLLKIykA9IPjQ== 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 AM6PR0202CA0057.eurprd02.prod.outlook.com (2603:10a6:20b:3a::34) by DB7PR08MB3129.eurprd08.prod.outlook.com (2603:10a6:5:1d::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5293.13; Wed, 1 Jun 2022 08:26:01 +0000 Received: from VE1EUR03FT050.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:3a:cafe::24) by AM6PR0202CA0057.outlook.office365.com (2603:10a6:20b:3a::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5314.12 via Frontend Transport; Wed, 1 Jun 2022 08:26:01 +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 VE1EUR03FT050.mail.protection.outlook.com (10.152.19.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5314.12 via Frontend Transport; Wed, 1 Jun 2022 08:26:01 +0000 Received: ("Tessian outbound 1766a3bff204:v120"); Wed, 01 Jun 2022 08:26:00 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 6f5e827ce8d63fac X-CR-MTA-TID: 64aa7808 Received: from 00c4b72d6778.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id E4AC45CA-88C1-4492-A177-B2FCD3224718.1; Wed, 01 Jun 2022 08:25:53 +0000 Received: from EUR04-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 00c4b72d6778.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 01 Jun 2022 08:25:53 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PAoTSqmZtl+XgDWDB5leRAqT0EDjsW0QT7q6SK//U0KY6bb86usu1iqNK1EF1GrfK4Zc6qcrp115eJyiy+qfmUoiX0MNU6qe1+sjFqbD4wZkEbqk6INAO8S6XlV9Oa87IRhdRPRO6vdat0UTYkX1H+DK9p+cvTyKmMMcbJIU0KUNoa5bNSofmE1xAsj9SIBkKHxqX8nmevzTpBzDQqm9FZHAZtApCeRGxByMamPIHfjZ7uSluPY+V8PjD5qDZQOI/EkIKPNulAVOeynMz8mZ9HXIZ4iAOsa/j1bAGqKUd76KywGw3QXsmTUWIa/R47nA/IC+D+Ng9QP+qi5Sxd+T2w== 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=1NRn4XVc7WPWQ/ukCazCnu+4Y8GVDFe3bfaqTvc4R6g=; b=PGjkfTO6gkRk+ydbBjetgpzb7Iej3pAJHxvT1lCBgxWfREraK6lKpBB0axPLvY7JjqtIuyxkTLxfFq5BrJbtMHXDYLO7wWZzgJFq+kL1/oIbejPCgI0Td8zReMJ2C2GAi4K4w3RbOPG0o7Dkf1M3+V2khXfS40pFJveBfr7sIZaWX6QtMb3V50R4rV8w81YW5SVUrYNOvEgRNlhDe5RpsLSKqIrvQvLrdAiaQ6nzl4UTOnCqLlVIrrNAOIb7ba2OjWrRhXbv9epa/1yfxmr7JrUtbl3NwwzvMUp6PHlUFRioGZnbuA8bYQhjC816uFfRM3k3deg5shKDSFycFMdeBg== 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 VI1PR08MB5469.eurprd08.prod.outlook.com (2603:10a6:803:132::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5293.15; Wed, 1 Jun 2022 08:25:52 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::9545:ff73:df89:3e50]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::9545:ff73:df89:3e50%7]) with mapi id 15.20.5314.013; Wed, 1 Jun 2022 08:25:52 +0000 Message-ID: <09afe250-9573-45e1-993b-a2f911f03630@arm.com> Date: Wed, 1 Jun 2022 09:25:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH 5/5] gdb: native target invalid architecture detection Content-Language: en-US To: Andrew Burgess , John Baldwin , gdb-patches@sourceware.org References: <71a986a5-2cfa-543e-4034-70f3af7dfecf@FreeBSD.org> <87ee09d4rt.fsf@redhat.com> From: Luis Machado In-Reply-To: <87ee09d4rt.fsf@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0398.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:189::7) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: c7fc3a1c-86fe-4830-05dd-08da43a85c8a X-MS-TrafficTypeDiagnostic: VI1PR08MB5469:EE_|VE1EUR03FT050:EE_|DB7PR08MB3129: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: yhMgcx8WmGHPH+0HOhMTHKlUoGXapA/+avx2PBYet/LwChMU68Zmw7EoK0W+QNeMzN/ZhOYlC0d3XhQSUmzhsS0m6h616MENZ3TRG4vs5HA+1Lc69toHcuZOtW8HwMuCk7JXuBcX+qliILAiEjjAmcqrn6nOSl759VmRH0TTY3XOIfz40QdBSt+tdy/2rf8LUeRYvGG6vEEA51P8EsE0XH5vzsRYWQpZ0hN/JjbEl9mfAlFiKlsn9wMlcEwDqvBHzrJQUM8BKxs1S6LWLzVFs1gQNQo9F6faVpdQXhQb1y+MjdvxSKAy94hw5laLdzeL9vhgN2b6QRgfxXDRgit0mVQdUICEJ2U5D4zX4hDOxOrV6YCI3ffVZ0CEITfRagWpwoxVgZFoZSbujfnMgBjome+lN1TENAuWijU7q9LxKd80ZcjZO2NkOeAs4wgEBjqatm5kRBiZxG0YvBmJ5cIuS9PyiYHY06VUUX9aDaZ7+BLBBv2ATzLikzFXRwf7MqH04hM9i/xPSFyKY+1ZEKzauPum9cqDjNq2Ab3HylZkCO8Fw7O8LhHOmlzJqjUHljMu0c/5E4cJFLsiPpEY0+nXea3h/F0d7aNP6AGc+/8kYWHs0ijp+oDDNwvkt94xmWYBjlbVCyvpzq+jGdn/Y0OYoLXZ/NWD6UjeCItw2ogQk3vICEIkCSr1lJgqhBQLkHu4YKlvntMzZRUUnTVOh7CZWYNTf6Mee8ilFfv/Yis+i1E= 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)(110136005)(31686004)(66476007)(36756003)(83380400001)(66946007)(31696002)(8936002)(186003)(2906002)(2616005)(38100700002)(6506007)(66556008)(6512007)(86362001)(53546011)(26005)(8676002)(508600001)(5660300002)(316002)(6486002)(44832011)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB5469 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: VE1EUR03FT050.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 032649d0-892a-49e4-f560-08da43a856ea X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ZECpT/Ir+qmw5jYxvWYUdHW9tb4BhCKCiLVkgHFdYVqO1NGkSU/s0mM1v6kcy/M2AwaNj+lfMf4NwcuStnvymXUSL5iL1Duwq4UDR6XsPncRyIs4me84k/3k55SMmRoXqrZO0Yra/+cgvM2g+PHlaoY17AGmJZyO8dKbSTWQSSmg+Fo0PkmoMl6YbdVBYqVNB1Ny2JwFmUuDS5EH9DqbnwUwLbAk5X3q6itJagndpQg2y0bWV+UICrTCyOlicThTzCGqNbw02Kr0sJDGmeeibegRHLGWsG8MVdZy9dIqOIdZ3P7U0enVZfi/H9ErnvFbBmyEOtZXW11AhScfAKcvOH9puNGqgrPXp4U+2L6jlnM/IAMeviVV4tsde+a5RVcRj6tIhL0o8b3080zvx0CkANpJcnSTfORsnbN28qFJfJ+NHq2av0UIrdLFvT4pr9SLn2uXGkeZ1oo8351yVRkEjShYOKH7WXTIyKf6V2KifgKodsZKraSXUlxtxjMNULsi9BjxzJuuofN1jdlqCBSbE8dSJHWpuXzkH1KM/ONPqjInlKoB9XdeLtf51xqWdOH5yAcIB1Cu8laN9P339ilmtEyKE8tKjFG/A3E4GSXuzPOTu7Wkz7gLPtF3AjBLulIYzcCq8SBgVP9MPfHEieG1Reo0U92hi8WQ+W3NRHAB2GshRm/LO1WZysGM86kx4+48APz2XitS0EhOHT8mMxAGKQ== 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)(86362001)(40460700003)(186003)(31686004)(336012)(81166007)(70206006)(5660300002)(8936002)(36756003)(83380400001)(316002)(44832011)(70586007)(2616005)(8676002)(2906002)(110136005)(26005)(53546011)(82310400005)(6512007)(6506007)(508600001)(6486002)(47076005)(36860700001)(31696002)(356005)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jun 2022 08:26:01.1056 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c7fc3a1c-86fe-4830-05dd-08da43a85c8a 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: VE1EUR03FT050.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3129 X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, 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: Wed, 01 Jun 2022 08:26:09 -0000 On 5/31/22 17:51, Andrew Burgess via Gdb-patches wrote: > John Baldwin writes: > >> On 5/31/22 7:30 AM, 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 make use of this from a GDB session 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. >>> >>> 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. >> >> Have you considered multi-arch cases such as running i386 binaries on an x86-64 >> host or 32-bit arm binaries on an AArch64 host? Will we need to override this >> method in certain targets (e.g. x86-linux-nat.c or x86-fbsd-nat.c) to support >> such cases? > > For the x86 examples you gave, I think these all have the bfd_arch_i386 > bfd architecture, so should work just fine. > > But for the aarch64 case, I admit I don't know how this works. A 32-bit > ARM binary is going to have bfd_arch_arm, while the AArch64 target will > be expecting a gdbarch with bfd_arch_aarch64. But how GDB supports > running the former on the latter, I don't know. > > I notice there's aarch64-linux-nat.c and aarch32-linux-nat.c, I wonder > if this has something to do with it... aarch32 is the 32-bit state of aarch64, but the BFD architecture is different. So this won't work out-of-the-box. > > Maybe someone with more ARM/AArch64 knowledge will chip in to fill in > some of the blanks. When attempting to run a 32-bit binary in 64-bit state, I get... The target does not support architecture "armv7". > > But to answer the general question, if there is a case that the existing > code doesn't handle, then we can for sure override the new method in > specific *-nat.c targets in order to handle weird cases.> > Thanks, > Andrew >