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 4B8183853547 for ; Wed, 8 Jun 2022 10:12:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4B8183853547 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 a15so19168487wrh.2 for ; Wed, 08 Jun 2022 03:12:24 -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=bzpmEC10yAJAK5WygUESF79oH7YtF2b2igUo6oj5wKA=; b=xUU8K6Ek0cOIwCwEcAMCkZjo4kG8to+hW8lnlPLFfGLec/QZhhdZ4xQhp4MoPnstRB Bj5ZYOCcqZztw5ZrBh4GtkoRWfBK9SsbYq14Uz7hfLsPAgd+PReUjP6bbzYZw9yaS94P rsTJfwlVpE2L5XyvzAeHCz53lJ4QBZDFkCWfjBeKaT/OYI5TSXRfYfUYULi7RUXlzPt8 L7Rzg6AmsuppS9ZZkTFRG6VT6zdrdmhdplqUvXPy811qkTa8lkIEU12b03uVre/VN5rP wvEMhcOVxerBCvRHRGYNsL1WdLrUsj9th4b+/bz2pxSrIMzsdcjt6iyUMsL+HDBLCn9X 79fw== X-Gm-Message-State: AOAM5302cbfvVX08w1h7WItTHUMaq04C/rpr0XfK49QMzx9wVRSYs/aV fgmjLsdBcbjBHpRzuSOqUn0= X-Google-Smtp-Source: ABdhPJyfJSNxhDr5pWJRIoLmIu0unUcEoI+mkLaJfnjeunllZycSi+wvucLzv18OPdxCKeKpSKAd+w== X-Received: by 2002:adf:fd84:0:b0:216:1595:82d3 with SMTP id d4-20020adffd84000000b00216159582d3mr22437165wrr.239.1654683143115; Wed, 08 Jun 2022 03:12:23 -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 q17-20020adff951000000b002103bd9c5acsm20754003wrr.105.2022.06.08.03.12.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Jun 2022 03:12:21 -0700 (PDT) Message-ID: <22be6164-79d7-c0f7-1b1b-c633be452e81@palves.net> Date: Wed, 8 Jun 2022 11:12:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH 5/5] gdb: native target invalid architecture detection Content-Language: en-US To: Luis Machado , Andrew Burgess , John Baldwin , gdb-patches@sourceware.org References: <71a986a5-2cfa-543e-4034-70f3af7dfecf@FreeBSD.org> <87ee09d4rt.fsf@redhat.com> <09afe250-9573-45e1-993b-a2f911f03630@arm.com> <87ilpdhn73.fsf@redhat.com> <87ee01hed4.fsf@redhat.com> <12c3913e-186d-b676-fe52-cc3322b00926@arm.com> <5c316bab-c2d3-309e-f938-7480e861b444@palves.net> <9c711ccb-a558-8225-524b-5a1fa93fcee9@arm.com> From: Pedro Alves In-Reply-To: <9c711ccb-a558-8225-524b-5a1fa93fcee9@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, BODY_8BITS, 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=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: Wed, 08 Jun 2022 10:12:26 -0000 On 2022-06-08 08:54, Luis Machado wrote: > On 6/7/22 19:42, Pedro Alves wrote: >> On 2022-06-07 12:03, Luis Machado via Gdb-patches wrote: >> >>> Yeah, sorry for the poor experience. I can confirm your procedure is >>> correct, and that you built GDB correctly. Unfortunately this part of >>> the AArch64 port seems to have rotted away given it is a less common >>> execution scenario. >> >> This is actually covered by the testsuite, since: >> >> ~~~~~ >> commit 71be1fdc3655a170f4b14d795e5c9e81fcea06ef >> Author:     Yao Qi >> AuthorDate: Tue Jul 7 16:58:19 2015 +0100 >> Commit:     Yao Qi >> CommitDate: Tue Jul 7 16:58:19 2015 +0100 >> >>      Adjust gdb.multi tests for aarch64 >>           Multi-arch related tests under gdb.multi are to compile programs with >>      the same compiler but different compiler options (-m64 vs -m32).  However, >>      different compilers are needed to compile both aarch64 program and >>      arm (aarch32) program.  This patch is to adjust these test cases to >>      compile programs in different modes with different compiler. >>           When we use gcc for arm-linux target, its file name can be different, >>      arm-linux-gnueabihf-gcc, arm-linux-gnueabi-gcc, or arm-none-linux-gnueabi-gcc, >>      so I add a variable ARM_CC_FOR_TARGET, so that user can set the name >>      of gcc for arm-linux target on aarch64, like: >>            $ make check RUNTESTFLAGS='ARM_CC_FOR_TARGET=arm-linux-gnueabihf-gcc multi-arch.exp' >>           gdb/testsuite: >>           2015-07-07  Yao Qi  >>                   * gdb.multi/multi-arch-exec.exp: Set march1 and march2 to "" if target >>              is aarch64.  If target is aarch64, set compiler=${ARM_CC_FOR_TARGET} >>              if it exists. >>              * gdb.multi/multi-arch.exp: Likewise. >> >> ~~~~~ >> >> I guess the issue is that nobody ever remembers to set ARM_CC_FOR_TARGET, or even >> knows about it. > > Yeah. As a general comment, I always have to stop and think about the list of things that need > to be installed in order for GDB's testsuite to run all/most of the tests. Yes. I think a nice solution for that would be to have a script under gdb/contrib/ that installs all the build & test dependencies on per distro basis. We have some of that in the old buildbot wiki: https://sourceware.org/gdb/wiki/BuildBot#Buildslave_configuration and also mjw's new buildbot infrastructure also is gaining some docker scripts that know the same. But I think putting it in gdb/contrib/ would be better so that everyone has easy access to it. > > If you're missing something, most of the time things show up as UNTESTED/UNSUPPORTED. It > would be nice to have a stable list of things we need to have complete (as much as possible) > testsuite coverage. > > Having to set these options by hand is quite obscure as well. Yes, hence my proposed patch in the follow up email. I think that we should strive to make just "make check" (with no options) Just Work. > >> >> IWBN if the aarch64 bots people have access to tested with ARM_CC_FOR_TARGET, if they >> aren't already. > > I think it is a less common scenario. Yes, this is supported, but my feeling is that people > seldom use this. Which explains why nobody complained, and some are surprised this even works. > A 64-bit program can always exec a 32-bit program. Likewise the other way around. That should be debuggable with a single gdb. As you say, it's supported. So, better test it routinely. Not testing it doesn't gain us anything, other than leading to bitrot, as has happened. >> >> Maybe it would be possible to come up with a way to default ARM_CC_FOR_TARGET to >> something that works for most people when testing aarch64, somehow. > The problem is that a compiler is not enough to make things run fine. If you have an aarch64 > Ubuntu, for example, you'd need to add armhf as an architecture option and install both the > compiler and the libraries (libc6:armhf mostly). That is not an issue specific to aarch64. On x86-64, you need to install extra runtime packages to test -m32 too, just the compiler isn't enough, and those packages aren't installed by default. > > Another problem is that not every processor/kernel supports running a 32-bit process in a > 64-bit environment. This makes things more complicated. > Why "more complicated"? If you're worried about FAILs in the testsuite, then we can e.g. make it run the 32-bit program once outside gdb to check that running 32-bits works. If that fails, then we don't run the test. Seems simple, not complicated.