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 608D63858412 for ; Mon, 11 Jul 2022 10:47:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 608D63858412 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-655-NPXUpvIxOa6Op0n7h7ChTQ-1; Mon, 11 Jul 2022 06:47:36 -0400 X-MC-Unique: NPXUpvIxOa6Op0n7h7ChTQ-1 Received: by mail-wr1-f72.google.com with SMTP id w12-20020adf8bcc000000b0021d20a5b24fso524278wra.22 for ; Mon, 11 Jul 2022 03:47:36 -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=atg9qKva5yhkHoryM1u+arLtMwthZtdpQkfQ+deRv7g=; b=wo2lB6Aux2WpBpOaRVwuSKTOSTpHkWeS5wE/D8XM9u1aZo8P7coFIArHq1DwigbC82 P/OJyQPFJt1KLRjS/o64VewtnCCMLpbDBx5WxRcEZNkuGYFjwBMGS4E3kNEssfgd7Lyn +1+EczZYyjKoenVM8JmMMmOIdCQKN15yecVM+adSRPFXnVIObaFeR4jmpsvBIk7eLGgP /FeDkSD83k/MDevEBe6y0qrX7yOG84X0uybHbeC9DDT6QIeVBj13EmznFQdM+Dvmt+AK Ei0e+r0y5ua4Q6+QG0MgoChLUDTNA8X+di2jvi+dYL7MbA+v96qd3crbL76qw5yv1BZX 6Z0Q== X-Gm-Message-State: AJIora911WIKGOKjphIuPNy20uZ4/QUXHnIOe/5HfyZVTCk2pnKhqHU1 D9nMdMDP5tT1sfRCOfNwtsvFa1IrL8J6Xm9syElAJ5eo+JZQGGUjCMACDhGZF7idhfd777aHIq6 MehK2YDLYqxM2cI2/iP4iPQ== X-Received: by 2002:adf:a51a:0:b0:21d:86b9:f41e with SMTP id i26-20020adfa51a000000b0021d86b9f41emr16393219wrb.217.1657536454824; Mon, 11 Jul 2022 03:47:34 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sYrWnS1uqFdWU/DvkNYziQAudD/PQme+Kbo1gImMV5DzlmLtKCEVz6LUsOsdqCHL5LzcQmgQ== X-Received: by 2002:adf:a51a:0:b0:21d:86b9:f41e with SMTP id i26-20020adfa51a000000b0021d86b9f41emr16393199wrb.217.1657536454571; Mon, 11 Jul 2022 03:47:34 -0700 (PDT) Received: from localhost (15.72.115.87.dyn.plus.net. [87.115.72.15]) by smtp.gmail.com with ESMTPSA id l23-20020a1ced17000000b003a03ae64f57sm6382637wmh.8.2022.07.11.03.47.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Jul 2022 03:47:34 -0700 (PDT) From: Andrew Burgess To: Pedro Alves , gdb-patches@sourceware.org Subject: Re: [PATCHv3 6/6] gdb: native target invalid architecture detection In-Reply-To: <0b9bee5a-d2c6-33f6-c3b9-67b9457add22@palves.net> 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> <0b9bee5a-d2c6-33f6-c3b9-67b9457add22@palves.net> Date: Mon, 11 Jul 2022 11:47:33 +0100 Message-ID: <87mtdgsz7e.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=-4.7 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_LOW, 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: Mon, 11 Jul 2022 10:47:39 -0000 Pedro Alves writes: > 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". Thanks, I'll work on splitting this patch, and repost. Andrew > 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.