From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.freebsd.org (mx2.freebsd.org [96.47.72.81]) by sourceware.org (Postfix) with ESMTPS id F0FB0396E47A for ; Thu, 2 Jun 2022 14:56:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F0FB0396E47A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=FreeBSD.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "R3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 34C13725FC; Thu, 2 Jun 2022 14:56:22 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LDTc60gnpz4p0p; Thu, 2 Jun 2022 14:56:22 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1654181782; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5ynrH41ueeqVD2m9v/hOwcKAFC4FA8Va3PdKvMPR/UQ=; b=Rd496gkNG5l/LJyzbOxr0kTMSC2LkOmgsC7izsxSZCWAiNQ72wHdlw6pjTdNa/jK83yNBl k2Fz5p+bKliLAd+KfSPzvoIt36WYkxMMGy+8yVS517aFSWLzmA/V2glVvtbUUeZ015762Q l+a+Z/SDZ+mGIqLAGHtIwKLQBm+S/11qTIWHX30wBvZAslgxstQrY42njqM2Lw+eKGjELJ r+w/h8dOQHzWvL4G5sN3vx++VpqjuEwc3AWuqeAHAetQ6fFdKMn6lDy04D8xj5/Cgr40qX kIo6Q8wJihXHkB1IEoDroXasmeamqkE+f8OF9o1s9PbpVTUYMlVjh7lJNnKhYQ== Received: from [IPV6:2601:648:8680:ed60:61ca:e5b:3600:f5d1] (unknown [IPv6:2601:648:8680:ed60:61ca:e5b:3600:f5d1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 1D44026187; Thu, 2 Jun 2022 14:56:21 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <9ba1ee1e-cef8-fc65-6895-27ca9838e9ec@FreeBSD.org> Date: Thu, 2 Jun 2022 07:56:18 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH 5/5] gdb: native target invalid architecture detection Content-Language: en-US To: Christophe Lyon , 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> <7308c0cc-1ced-1169-c65a-f1ae593b6d00@arm.com> From: John Baldwin In-Reply-To: <7308c0cc-1ced-1169-c65a-f1ae593b6d00@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1654181782; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5ynrH41ueeqVD2m9v/hOwcKAFC4FA8Va3PdKvMPR/UQ=; b=TMvMb/q8oGehu+9CLI9iIMCEOv1YplRuyOp+ZRAzUw1Uj6TapOH7ffjRmiZFV59C96cmc0 EaTXWCfN8ARN2AyiBYlhMGz5p3WuHbZWq2CHlWwye7mMLW3UzlCuGtusWN+EN7757sJs5P 92NyzaIRIJUtjwfErkg9T2IFRajvsItbn6ubO1gtlW86kY9SJIbOknPW+vq3mOl7JG9eEf 1riFman8ekvnTygalBx29uGAWTI71d3fbP0QXf/A40sGvGgPCPq9LUbR3m3hE7A9CBg5Gt ybkBtYYiqSIn7nHhE1U3kvoUXn3QX5DSwIMDhVlYrwWEPCTkGtBWq7no4DgGQw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1654181782; a=rsa-sha256; cv=none; b=HqPOthj61UXHOECy8ltxWkwldVrlJIbZnh/7F/K8DgQsn58en4jMYlQQ9yJBS+9dq5pTIc nSI/bKKwZCsb+OEeF4X+P/IA/7qq5y29hR9u8fp16Po0Hp+Zc5D0YQxn8GMkzWJsRVzmQV Kd/DcGeQuVfVraZVJ1UqN3++hjY6zwHDT++lEYu7aO+W7vFIEJUXgJc+jtQvIPKgpEwT0+ 2QNeTWQh012ye2lGSAtMzRfXu8fxZ6oPk9/bjBsbLzaX1Fum2VLeGR9vMCs/srG5nIYeId gvCwaTKcb/eAOoqGOt2v7MpjYQjbOAl+e97j/Hw2WNz6uKg+wSFt0HwVunaW2w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE 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: Thu, 02 Jun 2022 14:56:24 -0000 On 6/1/22 2:21 PM, Christophe Lyon wrote: > > > 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) Ok. FreeBSD supports this too, but I think it's fine to deal with this by overriding the relevant method in the aarch64-*-nat.c classes. -- John Baldwin