From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 13D66385DC16 for ; Tue, 31 May 2022 16:51:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 13D66385DC16 Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-137-Xkp7P4A-OvaLArzi1ykmhw-1; Tue, 31 May 2022 12:51:37 -0400 X-MC-Unique: Xkp7P4A-OvaLArzi1ykmhw-1 Received: by mail-wr1-f72.google.com with SMTP id h2-20020adfe982000000b002102da95c71so1126447wrm.23 for ; Tue, 31 May 2022 09:51:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version; bh=F6rfnybpL10yxoLeibj86nhxsEl/OntfjzyIflZnaDs=; b=zcF4E/69mLNzBHh6SxpBEdZsVF/t9GdsS5u8qaBtWDsbNywhAx1QVYbfMrCT5k9gUd 1Pc7MOaeDwi0neb7wqgtcl2fpLOLQtqlGjisMi1iE7btW/iB9tvvZCQ/y4EYPnLJ8CNq 6++6jMRlGQa5TYrU1ws8McvcRi+2tM2jSGUPGreuqhwkGFMoF8DGjaNVjyvWLIUPBz5M RIdkOAHFr2wVqAE3yMz9e1LTMz3ayKTek9rAuW44AHDJIv6eVroi9iNQYDQ8KgR8rLwJ h/o1F4dfnVUEJRoYdwEYLMbNbdK4ye7JgXg8XEFN5M+0bRuDzOlk6F/DB0jON8alAewm oE1Q== X-Gm-Message-State: AOAM532C/Kh1cB0MGqdOAmqXW7UVgVsxB92td2LXBKkYbBVfqmuwV3od YBvDXHOsjbLeEYoVYV1XLq2zQE+CJHptvbrkr+ktPU6rfv8viVVf1dLU3ENZ5a7jnzOxC8ufyKc D0OPWy9Fg8wlnKAxzJTJhWQ== X-Received: by 2002:a05:600c:2e14:b0:397:5a83:6578 with SMTP id o20-20020a05600c2e1400b003975a836578mr24316755wmf.201.1654015896085; Tue, 31 May 2022 09:51:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwMNtk/YC8G2q2nSvP1xbSNjnaJPnz6znA0MYmtDE7B4WmYQqUOeO8beRaxCPjJQq/FqGOD2g== X-Received: by 2002:a05:600c:2e14:b0:397:5a83:6578 with SMTP id o20-20020a05600c2e1400b003975a836578mr24316728wmf.201.1654015895826; Tue, 31 May 2022 09:51:35 -0700 (PDT) Received: from localhost (host109-152-215-36.range109-152.btcentralplus.com. [109.152.215.36]) by smtp.gmail.com with ESMTPSA id q12-20020a5d574c000000b002102f90870esm8066291wrw.108.2022.05.31.09.51.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 May 2022 09:51:35 -0700 (PDT) From: Andrew Burgess To: John Baldwin , gdb-patches@sourceware.org Subject: Re: [PATCH 5/5] gdb: native target invalid architecture detection In-Reply-To: <71a986a5-2cfa-543e-4034-70f3af7dfecf@FreeBSD.org> References: <71a986a5-2cfa-543e-4034-70f3af7dfecf@FreeBSD.org> Date: Tue, 31 May 2022 17:51:34 +0100 Message-ID: <87ee09d4rt.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no 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, 31 May 2022 16:51:40 -0000 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... Maybe someone with more ARM/AArch64 knowledge will chip in to fill in some of the blanks. 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