From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70089.outbound.protection.outlook.com [40.107.7.89]) by sourceware.org (Postfix) with ESMTPS id 9C0D9382BD01 for ; Tue, 7 Jun 2022 11:03:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9C0D9382BD01 ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=Z46XVsnUnf2oMpGcXPqJrw/STzgaktOHzY83fPQJ/tTZwvLe/snzmy40WrP25cqi1KIffwhBmw3kB7wZQtZEu+9MaDZlzo/YG6675TzaSFw3wlNLtYRLKWAproI+Xirt0FjHEBVps7e39TQ+XTOC2RxjJoqzqmK5V1KmHQBKzSrmJGO/Z4gTJ3Fo5sl5px5kICjOFd0OSzZjuXfsX5F2BJEH2+SIPdau6gAVxZuOwRTwhwaZeYLLevMeAx+tTUHuk+s5Yg26gLi9F2oLP0zqAJUrUpJx8Mw9wWQcL9FVf/f7kErbfC9EwbQ6ZYpNGGKHBcNmte0quhMc5VvdrliWeA== 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=s1TR52MRE6rwMQHNagMmraawF1qMX+XuXvsOekilbNo=; b=iL9IHL2ozptj9nCfJ4gZrWFg52WRVgPhM49W8qGNN+bX6xB/855nDuM/0OmRa88zy/cPB3pbn/EprAj9vcwCG6DPeYe64CsHo5QZFrT6eN7SQrvWk+xbriz5nRWuRJFyhHa9FLJ3v7y38Iroh4sualHjUlVNNH+7s4SPYC6rP3595nmTqyQ9YXwCsXrW2ZYqej8U7f/UgxpST30cNm4Ar6u7Y8tE98QIU26xOJkKdX+0YBS8LWplShK9JnXzKGxYqVviMH1LIi5C1/m4fQxN+LInjh6Q35cwL5DMuG1aRBQgye4sq/Rpu9VnSOffgMgM+cj/9wOBeSMSAmfqORqvmw== 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 AS9PR04CA0080.eurprd04.prod.outlook.com (2603:10a6:20b:48b::28) by AS8PR08MB6947.eurprd08.prod.outlook.com (2603:10a6:20b:346::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5314.12; Tue, 7 Jun 2022 11:03:51 +0000 Received: from AM5EUR03FT014.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:48b:cafe::f5) by AS9PR04CA0080.outlook.office365.com (2603:10a6:20b:48b::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5314.19 via Frontend Transport; Tue, 7 Jun 2022 11:03:51 +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 AM5EUR03FT014.mail.protection.outlook.com (10.152.16.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5314.12 via Frontend Transport; Tue, 7 Jun 2022 11:03:50 +0000 Received: ("Tessian outbound d3318d0cda7b:v120"); Tue, 07 Jun 2022 11:03:50 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 28c8672e321da416 X-CR-MTA-TID: 64aa7808 Received: from 3aa79a14eac7.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id BD50A203-E332-41F1-B8C1-1E8F43861B75.1; Tue, 07 Jun 2022 11:03:42 +0000 Received: from EUR04-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 3aa79a14eac7.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 07 Jun 2022 11:03:42 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oEaRtzvz/BoLBzDszMBh+RcaZzyuL3+jT1aGWmkUSrQVB3Qmp2oUBKwjKDH7B3Uos4zTlM68F0r59xoRPgGujYZKrrFaJauxSj4E7xnSwj8OrT0LH3ao183dFsDJRhBwtmSHa6wj+3ozzdGjKorN/53caqiF5gdDMzbfBahvv39vRsFYKUPQguo2dPeUP4Zvgb033xIeLEl5VF7IWXlRrOcOCi6upjqhjkcz3ywbRmsstl+hhTFt3n3RHg62h8vhDRFzaKvQew0UADadzYxorLYte01r/lIgSHrg5x1R2Nv4Zs+HwauwDmQ3IfMNeetXQ7nHQarsbVw3dpKul8j52Q== 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=s1TR52MRE6rwMQHNagMmraawF1qMX+XuXvsOekilbNo=; b=SZ4IboriUtrJdA8c8G2+Om4uLlXg7Ids60f3Cy3x1eqYIHmWlPWqg2A+DUsMTZ/ij3BnoF3sSJFPnTi0sWo/vVeFZCH0hPkyIPtbmHklDrkWFhTF5682sJfbL5iiqoYu8Ht+qdDOieyl0PHmq6TljjpTpe26GSYEJLPEti+6QJT4a5+nj23AjgdbwYinJJ0KwCRn/OOKh5YA/izc1ggiYKxYbE5FqqQxF1661D43uRxh+GH1OvtDsIuZOODEPBTMVq/pKtDvsucC8qjU9ZXyhVVUKqSbxTC9I3dF7Q/NCu/OJcZgVVsHD54t2tdRloL+NJJtxHKM+7xKqzeG+a+HEQ== 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 DB9PR08MB6505.eurprd08.prod.outlook.com (2603:10a6:10:23e::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5314.12; Tue, 7 Jun 2022 11:03:40 +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.019; Tue, 7 Jun 2022 11:03:40 +0000 Message-ID: <12c3913e-186d-b676-fe52-cc3322b00926@arm.com> Date: Tue, 7 Jun 2022 12:03:38 +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> <09afe250-9573-45e1-993b-a2f911f03630@arm.com> <87ilpdhn73.fsf@redhat.com> <87ee01hed4.fsf@redhat.com> From: Luis Machado In-Reply-To: <87ee01hed4.fsf@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO2P265CA0265.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a1::13) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 824c3272-8028-469f-8511-08da48756770 X-MS-TrafficTypeDiagnostic: DB9PR08MB6505:EE_|AM5EUR03FT014:EE_|AS8PR08MB6947: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: ar5CuW1Ah0JiTOgyWT3pBWOMrWW2+tKZG5p3zuj0GpGktqNYD29sCuNQo4LfSBXbRuinyD1Zwm7RkwsnlYIptBoS5MMtxxkwqpIrpSwFqUyijaZ5JFBdS+CBGqW2GuqaHkp/xbQQPx9f/tn84gSJzncnmOfAkkf9+SLdJWqcPuXRycTXnNXUHS2dBVn66F0P7P6QYoNuvoVHjzuICBVBvpqw21AXwI9lQ8pgwn3KPWXob6hcf29J4D40zQlBukAO4LIK9ZeJvlmoxCspolXLFKMaKy+d3AdYxSwNF4wj+SDfjVpPh+ZAOLyESuZ9jXOO2cVuoFUdf5Q5WwY/qLP5FKAm5TMv3nHesx9oqM+k8W7/RgveE8awsq4/d0ZBA5eRhgvcoprUv/HAZlLtTsVKvYM5CW9a0e+dns2HjOLE+uYSySPqSNSJcDhqEGQaC/rDqsvzRE1646XOFiMMa0GvUqI3ZyJHxD8xYM9qSGuCeLemWaaoWfqzbmMxWeomA3eqx45+naIEtH+dQGlIGJCH32XYVq/yBPf6LUx6/kUwLeDnQF1SvWYM8NSM2lpSLYPt03UNRtuh+Q/ktc69WgoPJL2eAKbCw17dfTr8ka9b2x49Zy2VmGEHQ7AO0TU/rB94RMGHq3rJBZ0UtLKEKoj2vXFwyJ92MO5mDiwN8DjycxQVZfeETovARyj5NNPRWWRDc4111z5kvX2IYq5WJ+t1iKok5FIkKhU+52ZvCv3DXz8CntAgMI+by+2Wu/4zcrnw 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)(26005)(8936002)(186003)(83380400001)(53546011)(110136005)(6512007)(21490400003)(2616005)(508600001)(36756003)(2906002)(31696002)(6486002)(38100700002)(86362001)(30864003)(6506007)(44832011)(5660300002)(31686004)(8676002)(66476007)(66556008)(66946007)(21314003)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB6505 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: AM5EUR03FT014.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 75bda8a2-daaa-4fa6-8665-08da487560d2 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: pVqacyqoGVc3gEZAqbHhRr37XLfcBEo1rqbB9+Fb1CY/ZLVZM5sL/d5xYvWqStMB45lD6Onz9EjFe/jTnLaAEU/sTcQlpZT2RSdzCwQYq05YOW2AUgnk6ecoyt+LrWxwc5eDA/5fYSFHtK25UMCW/cTXHEg57KCAwF4B2/WEahDXxm8IIg2XYZ66v9xif1SMYhw4VbdUIrsc9eYfLlYfYKxXcJb082daxEqjKyrvY6SFl+L/bnXVFbQ5/2u0xOm4IFwQxTNgGDI/kYHxCLbiuR+RFKR5bai1PC0U8ab+/zhYuLQXhoIzy8cRxW4mFTpKjRx0t4qk0yomHQjaPSmO770/8tHLDXwDv8SRP/nsf7dwLQRWP7K+daxAzv5wm3gTsR3FVdgXYB6DeGUgDtMcTdLXyadrkuJkli92QOftxbvUSYAiZ77JnbeLVOxbqIL7UqvUA+/nkv9oZL6SFTBdaz4wXVJKfPX5F3sF4uuIPmfVW+Y2A2eaQgXqnJvSoaJGItbmvsob7ywaU8p0F+LsM9XWWWR7T7txvyTPCO48v/rPAiPoiBtgucKQKyGEzFquezohvV36byQqI4mwGy4TlJqVIR1nAnM15WhlSO+gKxhdD8u9kb4TdsFLMfiv/qLPYqlnAs7SNbj0a8rNNAZJ6fV9C9yiZebre1Ol/5owWubHI817gdBgeiyzb6p9Mb4LE2gJQVqr1cQ79S04zzM1LkrHdBCq2KTT16j1WnzxFmg= 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)(82310400005)(110136005)(6486002)(86362001)(47076005)(40460700003)(6512007)(53546011)(26005)(36860700001)(31696002)(186003)(316002)(356005)(6506007)(8936002)(31686004)(81166007)(336012)(36756003)(2616005)(508600001)(83380400001)(5660300002)(21490400003)(44832011)(70206006)(30864003)(70586007)(8676002)(2906002)(21314003)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jun 2022 11:03:50.9366 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 824c3272-8028-469f-8511-08da48756770 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: AM5EUR03FT014.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB6947 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 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, 07 Jun 2022 11:03:58 -0000 On 6/6/22 18:48, Andrew Burgess wrote: > Andrew Burgess writes: > >> Luis Machado via Gdb-patches writes: >> >>> 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. >> >> If I understand correctly a aarch64 binary will have bfd_arch_aarch64, >> and a aarch32 (armv7?) binary will be bfd_arch_arm. >> >> What I don't understand, is how this all hangs together when running on >> an aarch64 machine, using a native target. >> >> Unless I'm missing something (please let me know if I am) then there's >> just a single native linux target, the_aarch64_linux_nat_target, which >> is registered from _initialize_aarch64_linux_nat in >> aarch64-linux-nat.c. >> >> In aarch64_linux_nat_target::fetch_registers, we assume the gdbarch_tdep >> is of type aarch64_gdbarch_tdep, so this will only work for >> bfd_arch_aarch64 binaries. >> >> Then there's the_arm_linux_nat_target, from arm-linux-nat.c, which has >> arm_linux_nat_target::fetch_registers, which assumed gdbarch_tdep will >> be of type arm_gdbarch_tdep, so will only work for bfd_arch_arm targets. >> >> So, I guess, if we can debug bfd_arch_arm and bfd_arch_aarch64 binaries >> on a native aarch64 target, we must somehow be switching the current >> native target object between these two, right? But I can't figure out >> where that's happening... >> >>> >>>> >>>> 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... >> >> Does this mean you're on an aarch64 machine, start GDB with an aarch32 >> (armv7?) binary, and then "run" to start the process? >> >>> >>> The target does not support architecture "armv7". >> >> I'd be really interested to know if you only take the first 4 patches >> from this series, can you still run armv7 binaries using an aarch64 GDB? >> I'm wonderinging if the assert added in patch #4 will trigger. > > I managed to get a setup where I'm running on an aarch64 machine, and > using GDB to debug an ARMv7 binary. > > I'm a little confused as to what's going on, so I'm hoping I can > describe what I'm seeing, and you can tell me if GDB is supposed to do > better than this or not. > > First, I'm using a modified version of patch #4 of my series (i.e. I've > applied patches #1, #2, #3, and #4, but modified #4), in gdbarch.h I've > replaced the _function_ gdbarch_tdep with this: > > template > static inline TDepType * > gdbarch_tdep (struct gdbarch *gdbarch) > { > TDepType *tdep = dynamic_cast (gdbarch_tdep_1 (gdbarch)); > if (tdep == nullptr) > { > fprintf (stderr, "XXX: Incorrect cast performed!\n"); > return static_cast (gdbarch_tdep_1 (gdbarch)); > } > return tdep; > } > > Here's my GDB session then, debugging a 32-bit ARMv7 binary; > > $ file /tmp/ubuntu-16.04-armhf/bin/true > /tmp/ubuntu-16.04-armhf/bin/true: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=c80229c22d4b6b30b71ab1b1b5a1de6b86b6aadf, stripped > $ ./gdb/gdb -q --data-directory ./gdb/data-directory/ /tmp/ubuntu-16.04-armhf/bin/true > Reading symbols from /tmp/ubuntu-16.04-armhf/bin/true... > (No debugging symbols found in /tmp/ubuntu-16.04-armhf/bin/true) > (gdb) show architecture > The target architecture is set to "auto" (currently "armv7"). > (gdb) starti > Starting program: /tmp/ubuntu-16.04-armhf/bin/true > XXX: Incorrect cast performed! > XXX: Incorrect cast performed! > warning: Unable to determine the number of hardware watchpoints available. > warning: Unable to determine the number of hardware breakpoints available. > XXX: Incorrect cast performed! > > Program stopped. > 0x0000000000000006 in ?? () > (gdb) show architecture > The target architecture is set to "auto" (currently "aarch64"). > (gdb) pipe maintenance print xml-tdesc | head -n 20 > > > > arm > > > > > > > > > > > > > > > > > (gdb) info registers > x0 0x0 0 > x1 0x0 0 > x2 0x0 0 > x3 0x0 0 > x4 0x0 0 > x5 0x0 0 > x6 0xfffef6a000000000 -291782898221056 > x7 0xf77d0b4100000000 -613321600451739648 > x8 0x30 48 > x9 0x8d03c8 9241544 > x10 0x23cad1e8 600494568 > x11 0x7fd7d9dce8 549082225896 > x12 0x7fd7d9dd00 549082225920 > x13 0x7fa10128d0 548162054352 > x14 0x23c3d8a0 600037536 > x15 0x0 0 > x16 0xd32a70 13838960 > x17 0xd32aa0 13839008 > x18 0x0 0 > x19 0x0 0 > x20 0x0 0 > x21 0x0 0 > x22 0x0 0 > x23 0x0 0 > x24 0x7fd7d9dd50 549082226000 > x25 0x412694 4269716 > x26 0x7cdf14 8183572 > x27 0x23b60ca0 599133344 > x28 0x4105e0 4261344 > x29 0x0 0 > x30 0x7fd7d9dd50 549082226000 > sp 0x23c3d8a0 0x23c3d8a0 > pc 0x6 0x6 > cpsr 0x6 [ EL=1 BTYPE=0 ] > Unable to fetch vFP/SIMD registers.: Invalid argument. > (gdb) > > There's a couple of weird things I notice here. First, obviously we're > casting the tdep field incorrectly 3 times. This happens because, > initially, the GDB inferior has a gdbarch selected based on the ELF, so > it will be an ARM gdbarch with an arm_gdbarch_tdep. However, I believe > that the native target will be aarch64_linux_nat_target. That's correct so far. Yes, the BFD will be arm and the native target will be aarch64-linux. > > So, when we first stop, after the target is created, we will call > aarch64_linux_nat_target::fetch_registers as part of the stop process, > this will perform one of the invalid casts. I haven't (yet) tracked > down the others. See below. > > The next weird thing is that, after starting, the architecture has > changed to aarch64. I have no idea why this is the case (I haven't > looked yet). I think this used to work, but eventually it got broken (rotted away) and now it doesn't work properly it seems. My guess is that the introduction of SVE support also changed how we look up the target description. In this particular case, I think we're calling the aarch64_linux_nat_target::thread_architecture function, and that particular function completely ignores the existence of aarch32, so GDB ends up thinking we have an aarch64 target again. > > My expectation was that after the first stop GDB would ask the native > target for a target description, we'd get an ARMv7 target description, > and we'd then use that description to update the gdbarch. It appears I > was partially correct, as you can see that the xml-tdesc is for ARM, > however, the current architect still switches to aarch64, and I have no > idea why that is. I think the XML is generated from the BFD information, right? So that's why it is correct. > > Finally, in the 'info registes' we appear to be displaying aarch64 > register names, rather than the ARMv7 names from the xml-tdesc, which > seems weird (again, I haven't looked yet), and then, at the end of the > 'info registers' output we appear to try and fetch some registers that > the target doens't support. They're aarch64 registers because the aarch64_linux_nat_target::thread_architecture function told GDB we have an aarch64 target description. That's incorrect. The other errors are just consequence of incorrect identification of the architecture. > > If I try the same experiment using an aarch64 test binary then the > architecture starts as aarch64 and remains so after the 'starti' (as > you'd expect, and the 'info registers' output still displays the aarch64 > names (as you'd expect), but the warning about 'Unable to fetch vfP/SIMD > registers' is no longer present - so that issue is something specific > relating to running the ARMv7 binary. > > I think there's a lot here for me to look into, but I'm hoping you might > be able to let me know if me experiences above are the "expected" > behaviour, or if I'm not configured/built GDB correctly, or maybe I'm > just not using GDB correctly in this ARMv7/ARMv8 situation. Yeah, sorry for the poor experience. I can confirm your procedure is correct, and that you built GDB correctly. Unfortunately this part of the AArch64 port seems to have rotted away given it is a less common execution scenario. The most exercised cases are to use a 64-bit GDB (aarch64) to debug 64-bit binaries and a 32-bit GDB (arm/armhf) to debug 32-bit binaries. The aarch32 code path is what you're exercising here, using a 64-bit GDB to debug a 32-bit binary. I'm not sure if there are other ports out there that can handle multiple different bfd's natively, but I don't want to block your series. We can address this through a target hook that tells the upper layers we support X and Y bfd's I suppose. Hopefully this clarifies things a bit. Let me know if there's any other information you need. > > Thanks, > Andrew >