From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80059.outbound.protection.outlook.com [40.107.8.59]) by sourceware.org (Postfix) with ESMTPS id 4CEF5384B0C9 for ; Wed, 1 Jun 2022 21:21:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4CEF5384B0C9 ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=VglB3kVPMg2in7V+GlnLuD1VTEMWkKL1oatOj8ktxKNRKbwAOgA/NvBVZcaJto2sAnDzNhBJceJc2RZSkov1OzXPwEvjUKi2yX3LSz362ahiAuA8zPUJk7cHO5etWWuQk75EI0txfAmw8YUDS+oqTgM7AmHyARrkNgMbBUIT/15t7O8TjAzley+tjCO5+yc5QGR4yci7gG/ASGdjil07IvUwjvNeWXJW1MM1MVtzKJj01fzgkMgQyw/VD/HZJq3K6mRrGV79xfl7Qxbkpl2aTuLo8LFl+vHXWuJ4BFN4uqW9LRZyH94yma7Tkfzie2WwGp0X87NZuKVxnqVtq5k27Q== 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=gLrbTErqT6lJfJHVZ4+ulLAD2oZ7KEhiZSQNSte4Lg4=; b=SaFJ09lWM2HNAu9eDlx6jn3la43rPGs/pBw9yqAmTKy+fTxeeLglIiJixy7Bjnk2S4QQ1Ty+9IbIdxchiQr0G7BPHavo8+2qbg9uzFIAc9fKe4hxrlwxjZgYzJGnxXFcHknkZF76ZGjy9I5BcgBXl2WosyAxj1fx2swMr4B8a9ngHhj1TnMbWr9I4WQxxlSUfk3N7/YbjDZJjK/UBHjAERfv1HKIsQUZqwUyDAhwYPgvaxL7ucz4OWQmECgUHU2r+5XT5T9uxjrJF0AAmjx9T6epxu5R8btgEWuQx83jCnbfp+s8/ZakcEePY+c5I0H6WSvT1q9efkrhcOfgfB+Eag== 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 DB7PR03CA0107.eurprd03.prod.outlook.com (2603:10a6:10:72::48) by HE1PR0802MB2603.eurprd08.prod.outlook.com (2603:10a6:3:e0::16) 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 21:21:29 +0000 Received: from DBAEUR03FT022.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:72:cafe::37) by DB7PR03CA0107.outlook.office365.com (2603:10a6:10:72::48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5314.13 via Frontend Transport; Wed, 1 Jun 2022 21:21:29 +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 DBAEUR03FT022.mail.protection.outlook.com (100.127.142.217) 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 21:21:29 +0000 Received: ("Tessian outbound 6f53897bcd4e:v120"); Wed, 01 Jun 2022 21:21:29 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: b22de046bcce2b79 X-CR-MTA-TID: 64aa7808 Received: from a5e42612c2f7.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 452AB00D-AD6A-4BE4-BF01-9EDD44F10873.1; Wed, 01 Jun 2022 21:21:22 +0000 Received: from EUR03-AM5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id a5e42612c2f7.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 01 Jun 2022 21:21:22 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SoGTmvrZXekuVR8pSG6NO86tOrriNczrmxvmF98nQANyOa+4itx0JQgpx23ao8mMMYIfSUbmpQ+SfwyroimKcagc72pwzjdaRum1a8iHh3HyDaW+4/xxQnZBtWOHccyYUnvLhSX1WQfsID0MO9kKhk9wwf46eP+yzPKx7RlbmAIzX0xKifOVabgOFl40+xYkSywxlX3TDNxsCiIbHkt/suVbcgty+n6erxEs3/zZR4U+bPSAXwOvJ/VGD6pgjGIBzjbLMX2vxOBi3MjERKaxN655lVlrnZSRt+Iuy5e9HsgMAw11iXekBNDKSNcK2vO+n8aYs69CQjS2ECNJ0qLqUQ== 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=gLrbTErqT6lJfJHVZ4+ulLAD2oZ7KEhiZSQNSte4Lg4=; b=baPUQup+l32oJWgY8lHeYbsVUdPEE+0B2Pl3yWDlAcxfTmlpg2wIJsIyJIXcJF3G8Tkt8x3Vr5p8fQEbqYXkUb76yBckY1t33abf4B/YdO2r3UOeP6R0SLHgnJPxO7wveaZu51Aib9g9bZrdcjUGKt2ettmb1Uzs+61BDTd9tp9dFKfQ74EUlixSfCiJTFYe05cKi/YSrRbyadUyp8eQ2/W/OoAHRKG2iZmG6lrw0Whk15ch6okMueu4JSJgYcbWzPZu5WR+qh7ZxEuoJ2mRPusTEfzaILRvP5mr9IxwVnQ1OmgL2SD8+0el6QAMqhnJukDJLBjHy0LpVH3pSGF2JQ== 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 VI1PR08MB3390.eurprd08.prod.outlook.com (2603:10a6:803:7d::27) by AM9PR08MB7291.eurprd08.prod.outlook.com (2603:10a6:20b:436::18) 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 21:21:16 +0000 Received: from VI1PR08MB3390.eurprd08.prod.outlook.com ([fe80::4cab:84d0:9b6c:a39e]) by VI1PR08MB3390.eurprd08.prod.outlook.com ([fe80::4cab:84d0:9b6c:a39e%7]) with mapi id 15.20.5293.019; Wed, 1 Jun 2022 21:21:16 +0000 Message-ID: <7308c0cc-1ced-1169-c65a-f1ae593b6d00@arm.com> Date: Wed, 1 Jun 2022 23:21:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH 5/5] gdb: native target invalid architecture detection Content-Language: en-US To: John Baldwin , Luis Machado , Andrew Burgess , gdb-patches@sourceware.org References: <71a986a5-2cfa-543e-4034-70f3af7dfecf@FreeBSD.org> <87ee09d4rt.fsf@redhat.com> <09afe250-9573-45e1-993b-a2f911f03630@arm.com> From: Christophe Lyon In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P265CA0363.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a3::15) To VI1PR08MB3390.eurprd08.prod.outlook.com (2603:10a6:803:7d::27) MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 4db11bb6-e55d-43c5-0391-08da4414b154 X-MS-TrafficTypeDiagnostic: AM9PR08MB7291:EE_|DBAEUR03FT022:EE_|HE1PR0802MB2603: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: sPCAQjxOH02iLRNP5lDr0sPkbP1gk7gmznjjx0Ru7atq2RTQx0SvF1r9U/vI6uZBWgozC1zj67jkPC3qPud2j82R9OEKO1CcKvmp6WvJUSsHfLBulTdo/lbEvbXgB0X4XO5O49I5fbxfIWmm2UuGeCakv9K5Ysj1psl5hnz+i9i2ejUZyeQhKSIFn+Zt3FISVsC4MkyMPLp+xU/FCkPd4Tb4zOWW1I9eTaA+GqjD0YfzvkBqKpJ8Hl+PDNsLs2okRReMJ3pe1ZHUZmxY6ewjyHveiVPVJHDYr8qWObzjip5vx+WHtuAI9ghOTt0KsjYwWcnTZQ6B3AcSO/ll+VRSmhrnrtKum/RR6cARqTzjkIQ4625BS8LvuGJB9vdo/9gld88ayhcLHpR8giOC0E8AEsWbgCyvb4GoDizBtnnW7LSaqmqLcftANwePOJj/bu0R1k/wlDfxVtTN9AmkNmVXbjIz4Fcf2NI6dwBultaB55Firn/sSI8ZPVlJFA6WD5KPSekZGVJG+5fBum84Tr3QTHigcIWsh7unERAQLFZVJW4s3Sb4Hw/bKRLW9H8xc60Qoou8PhxICqF4LibJimqcn+s6cyQucCIbYZ1vUBj8LvnrutMQ+e5LdjBhcPTGW1UBQ3nvmghMjPItoQtDBm0AYN6QoFRCfFlsdoGG7AacRtvxTV8axKDFubbNJFVwd6STodB1jp6WK7nXUXJGYgJwRV4pshpG2xuChx2f5puSSeU= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR08MB3390.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(26005)(83380400001)(6486002)(66556008)(38100700002)(66476007)(8676002)(53546011)(6506007)(186003)(8936002)(508600001)(5660300002)(36756003)(86362001)(110136005)(31696002)(31686004)(2906002)(2616005)(316002)(66946007)(6512007)(44832011)(6666004)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR08MB7291 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: DBAEUR03FT022.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: de280263-88ac-4b0b-cf96-08da4414a96f X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: oY11d8lpETnnSbv7CUBBDE3r8v/+9Zl3+YqFgigdVwJnUI6TbXiQSIOwN8Qs1KBxmVn4IyO/y8DDJHoWnmKv5jFpJ+kOaHlzy+bd9NHqR57v7Af5EvHg9v+gQ1PBz80pZ3hxd6rR8DQNlwRZs3EdRwaFKe3cviHRNr4BnFhhZC3IU3Iwwo8ziBZ/nl94h04BAV/OMXXgSyp8VDgVd4EyGXjO9OJbMi438I13mNgEfq7QQHP4TNg/ah80HNSBAmZWPKP8kLOU7IVwdoJ4brDmq5c2sVFx4+MjmSuWvojJ+cwZ8xslioN9rwHdtZxyytblwcuD4QZfjvGltJWS4vlMl/1nnlt58vOQxVT/MktUFFDVWI6vqk/ZCWb5XNnAKXw4zRekld7Bj0wIAh2aSzDzilT1AMd+IjU14Rdfo9uhhS11ofBFfwfdjP1V3fVTQ9QUq5FRI3pHigGD3gW1hO75Y66OnPVT+YyfeW1Z5tvj7v4AIk5nG7Wsdq1O+xrJCUmpjBHujHT6IE8F5trrUXpo44/BGMiPJYS3WJbtitBTGz2tAngJo77+hYZm3iRfZx4sM6R2fYaf3Kh++QAwOrbUYxeve7R8XWFZDUoMV4Xj8txr5QjOLvUXP7GUkUJrfSb3aMIBmM2fNIPRZrdQ72EV6DeYhP8yLnuwmzKQl+jwPyDWA3pxb7lOoQEk2o7Sq1fv8ZsUqVhwP64UwngWGl5W5Q== 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)(40470700004)(46966006)(36840700001)(31686004)(36756003)(36860700001)(83380400001)(70586007)(70206006)(31696002)(81166007)(186003)(8936002)(2906002)(336012)(82310400005)(2616005)(6512007)(110136005)(8676002)(6506007)(86362001)(53546011)(26005)(356005)(40460700003)(47076005)(6666004)(508600001)(316002)(6486002)(5660300002)(44832011)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jun 2022 21:21:29.1298 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4db11bb6-e55d-43c5-0391-08da4414b154 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: DBAEUR03FT022.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0802MB2603 X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, BODY_8BITS, 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: Wed, 01 Jun 2022 21:21:37 -0000 On 6/1/22 23:06, John Baldwin wrote: > On 6/1/22 1:25 AM, Luis Machado wrote: >> 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". > > Does Linux support running 32-bit binaries on a 64-bit aarch64 host? > Yes. For instance one can start a docker container in aarch32 (32-bit) mode on a aarch64 host (provided the CPU supports both modes, which is not always the case) Christophe