From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) by sourceware.org (Postfix) with ESMTPS id 66D023842AC7 for ; Thu, 30 Jun 2022 11:44:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 66D023842AC7 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f45.google.com with SMTP id q9so26888327wrd.8 for ; Thu, 30 Jun 2022 04:44:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=0YSQ+/aIOVF9UUjTKJMzphdQPhO3L0QWhkEeDMQnK8g=; b=ni+u8zGOZHYHr29g4HsoN85oI466fCqI0+mfiommNV4dAm21GDv1dY88xOMHeb51lo VQN3c9poSnVbJPPPToTreMq75TKAy8zQ3vXWQGQ7YdLxkVSbZsiKxZNIlu9eS9Qjl0F1 ME4SJKMP/eBJ5Y2dRUB6T8qeHbn2pbd35uQpzUHYdnchv+i8pz1t04BqLw50EySzz5mc MSr/ipP0I1t4eU5plsW6Bg5vLLvBbatKR/E7TnxbjEVeGH5SXhRa5XCk0PVz0uyx2R0n Qn96YYqJ+3abWXAJLnxYNrcZHvyYtAa6fYRbBncCSFqbjIEKpkgcviLZzjBydLhgnUXC 1Oqw== X-Gm-Message-State: AJIora/ofURqXox7DVHLWYV9NcjO7hJCKYAZTUkM06MgfExdrbWFQ4cp 7NYXSptwwp9XLe21xdLX7ds6v7AEZpQ= X-Google-Smtp-Source: AGRyM1uItHVFne2ifATRTBnM33flkvo4ezo/xPxHVM/NPe0pcJslZG9RVcrXOw5ojoGfIM00Es7GHw== X-Received: by 2002:a05:6000:1885:b0:21b:ad25:8ae6 with SMTP id a5-20020a056000188500b0021bad258ae6mr7597711wri.183.1656589462281; Thu, 30 Jun 2022 04:44:22 -0700 (PDT) Received: from ?IPV6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id bk20-20020a0560001d9400b0021b8b998ca5sm18018649wrb.107.2022.06.30.04.44.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Jun 2022 04:44:21 -0700 (PDT) Message-ID: <0b9bee5a-d2c6-33f6-c3b9-67b9457add22@palves.net> Date: Thu, 30 Jun 2022 12:44:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCHv3 6/6] gdb: native target invalid architecture detection Content-Language: en-US To: Andrew Burgess , gdb-patches@sourceware.org References: <83ceec06f74f4ce6a2dc8d794031fb233567ba6d.1655136816.git.aburgess@redhat.com> <48d211cc-96f3-8c84-5aec-7023054d45ac@palves.net> <87fsjqdqco.fsf@redhat.com> <6db0b4b8-25fb-8f4c-382e-d45f6edcff17@palves.net> <87letecx7w.fsf@redhat.com> From: Pedro Alves In-Reply-To: <87letecx7w.fsf@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, 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: Thu, 30 Jun 2022 11:44:25 -0000 On 2022-06-30 10:33, Andrew Burgess wrote: > Pedro Alves writes: > >> On 2022-06-27 17:27, Andrew Burgess wrote: >>> Pedro Alves writes: >>>> On 2022-06-13 17:15, Andrew Burgess via Gdb-patches wrote: >>>> I have another question. I'm confused on how if e.g., on x86-64, you >>>> load a RISC-V binary into GDB, and the try to run it, we don't end up >>>> with architecture of the target description instead. >>> >>> The problem is that we end up trying to read the registers before we >>> read the target description. Which I suspect you will say sounds wrong, >>> and I agree. >>> ... >> Attaching will need some other fix, because in that case, the procedure is that the core >> requests an attach, and then the target reports an initial stop, and that stop >> makes infrun read the thread's PC, before setup_inferior is called. It may be >> we need to call setup_inferior earlier. Or maybe we can just add a target_find_description >> call in linux_nat_target::attach, like remote.c does: >> >> void >> extended_remote_target::attach (const char *args, int from_tty) >> { >> ... >> /* Next, if the target can specify a description, read it. We do >> this before anything involving memory or registers. */ >> target_find_description (); >> >> I haven't looked at that in much detail, and I have to leave for tonight. > > How about the patch below to solve the attach case? I think this should be two patches. The part about picking the architecture of the target isn't specific to attaching. We're counting on it for "run" too. > No test as I don't know how I can reliably compile a binary for a > different architecture as part of the testsuite. We don't even need a binary to trigger badness. Just need to manually specify an incompatible architecture, with "set architecture", and then "run". Like, with current master: $ gdb -ex "set architecture riscv" ~/gdb/tests/main GNU gdb (GDB) 13.0.50.20220630-git ... Reading symbols from /home/pedro/gdb/tests/main... The target architecture is set to "riscv". (gdb) r Starting program: /pedro/gdb/tests/main warning: Selected architecture riscv is not compatible with reported target architecture i386:x86-64 warning: Architecture rejected target-supplied description ../../src/gdb/i387-tdep.c:957: internal-error: i387_supply_xsave: Assertion `tdep->st0_regnum >= I386_ST0_REGNUM' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. ----- Backtrace ----- 0x556325d5365b gdb_internal_backtrace_1 ../../src/gdb/bt-utils.c:122 0x556325d53714 _Z22gdb_internal_backtracev ../../src/gdb/bt-utils.c:168 ... A slight difference here compared to actually having a binary of the wrong arch, is that this isn't "set architecture auto", so by making choose_architecture_for_target chose the target architecture, we'd be overriding the explicit user selection. Maybe that's OK, not sure. Maybe the right thing to do in that case (when arch is not auto) is to error out (and kill/detach the inferior) instead of warning.