From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) by sourceware.org (Postfix) with ESMTPS id 8D2B13854144 for ; Fri, 24 Jun 2022 19:23:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8D2B13854144 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-f50.google.com with SMTP id m1so4395978wrb.2 for ; Fri, 24 Jun 2022 12:23:19 -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=X6hqVR3oSTYt2uuEIBRzwICu21C9lO6dooFj9hSffqk=; b=ei3g/HhBjIDwQ5pCtJ7UjzIB3wP7491j/CmGcN0sj2rwI+RPPK91A/MLq4TXxp6Lh5 CC6iGqXyXaUew9tmnjNCzpBu1+aEFPwko0Wz2KwKIWWYNAB+nHyEPwILz6Dk8gkB20JL RJFnBLhsaCmUxpkYv6GgufY8RQQb3cWHaw+i3SkloKelIO23eh4W16YU75h7xjibFZAJ yoGOkCdN8aN6Pe8+h07514cQPRlAb1ral0qK0ILqyeQHd85Tu28Gav0XQ6KWCQVCJpwb OkHFJOSvvTpAIygk1RskEm+VS+ptZFStE8JmmGHz6EMcdAeiwNBxLNMkUe3Dmyx43G2X NGEg== X-Gm-Message-State: AJIora82cIh9ZOvDLXiXyTHzfq9EF7XL8ofaBI6ti+pZlzXX5nSxKAcv 5jXTa44rqmY+fNawl/QtvX4XLme2yqo= X-Google-Smtp-Source: AGRyM1vPw1k5xY5CK5wueUyLe4IonFopJR7nnaX3k/mg4ZMME4DMNRRtxUTk59y0MGkyhFXN/BrpXw== X-Received: by 2002:a5d:6d84:0:b0:21b:9acb:c478 with SMTP id l4-20020a5d6d84000000b0021b9acbc478mr597785wrs.491.1656098598467; Fri, 24 Jun 2022 12:23:18 -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 r21-20020a05600c35d500b003a02f957245sm7980040wmq.26.2022.06.24.12.23.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Jun 2022 12:23:17 -0700 (PDT) Message-ID: <48d211cc-96f3-8c84-5aec-7023054d45ac@palves.net> Date: Fri, 24 Jun 2022 20:23:16 +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> From: Pedro Alves In-Reply-To: <83ceec06f74f4ce6a2dc8d794031fb233567ba6d.1655136816.git.aburgess@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-10.1 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, GIT_PATCH_0, 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=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: Fri, 24 Jun 2022 19:23:21 -0000 On 2022-06-13 17:15, Andrew Burgess via Gdb-patches wrote: > This leaves just one question, what about native targets that support > multiple architectures? > 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. If the target reports a target description, and the resulting architecture is not compatible with the executable, then I think it would make sense to use the architecture of the target? If I start a 64-bit program on x86-64, like: $ gdb ~/gdb/tests/main64 GNU gdb (GDB) 13.0.50.20220624-git ... (gdb) start Temporary breakpoint 1 at 0x400492: file main.c, line 11. Starting program: /home/pedro/gdb/tests/main64 Temporary breakpoint 1, main (argc=1, argv=0x7fffffffdc48) at main.c:11 11 return 0; and then try to load the executable of an incompatible arch, like: (gdb) file ~/gdb/tests/main32 A program is being debugged already. Are you sure you want to change the file? (y or n) y warning: Selected architecture i386 is not compatible with reported target architecture i386:x86-64 Architecture of file not recognized. then GDB doesn't switch the architecture to the file's architecture, it is still x86-64: (gdb) show architecture The target architecture is set to "auto" (currently "i386:x86-64"). and it doesn't let me manually select an incompatible architecture either: (gdb) set architecture riscv warning: Selected architecture riscv is not compatible with reported target architecture i386:x86-64 Architecture `riscv' not recognized. The target architecture is set to "auto" (currently "i386:x86-64"). (gdb) It kind of sounds like if GDB detected the incompatibility when we first fetch the target description, similarly to how we detect it in the cases above, and GDB picked the target arch or errored out after detecting the incompatibility, then we wouldn't need a patch like yours? How come the mismatch isn't detected then (when we first retrieve the target description) today? > + > protected: > /* Unpush the target if it wasn't explicitly open with "target native" > and there are no live inferiors left. Note: if calling this as a > diff --git a/gdb/infcmd.c b/gdb/infcmd.c > index e909d4d4c81..b8acf858b3a 100644 > --- a/gdb/infcmd.c > +++ b/gdb/infcmd.c > @@ -413,6 +413,10 @@ run_command_1 (const char *args, int from_tty, enum run_how run_how) > if (non_stop && !run_target->supports_non_stop ()) > error (_("The target does not support running in non-stop mode.")); > > + if (!run_target->supports_architecture_p (get_current_arch ())) > + error (_("The target does not support architecture \"%s\"."), > + gdbarch_bfd_arch_info (get_current_arch ())->printable_name); > + > /* Done. Can now set breakpoints, change inferior args, etc. */ > > /* Insert temporary breakpoint in main function if requested. */ > @@ -2590,6 +2594,10 @@ attach_command (const char *args, int from_tty) > if (non_stop && !attach_target->supports_non_stop ()) > error (_("Cannot attach to this target in non-stop mode")); > > + if (!attach_target->supports_architecture_p (get_current_arch ())) > + error (_("The target does not support architecture \"%s\"."), > + gdbarch_bfd_arch_info (get_current_arch ())->printable_name); > + Since the error is the same in both cases, I'd suggest putting it in a shared routine, like: static void check_target_supports_current_arch (process_stratum_target *target) { if (!target->supports_architecture_p (get_current_arch ())) error (_("The target does not support architecture \"%s\"."), gdbarch_bfd_arch_info (get_current_arch ())->printable_name); }