From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) by sourceware.org (Postfix) with ESMTPS id 13323383D825 for ; Wed, 8 Jun 2022 21:48:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 13323383D825 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-wm1-f48.google.com with SMTP id h62-20020a1c2141000000b0039aa4d054e2so14061290wmh.1 for ; Wed, 08 Jun 2022 14:48:59 -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=iOqWUiAaFI4d6+NV3+C9dZqO/kHJdLS/zjD3Kblf/vA=; b=oGeYs3dOeYJqke+AXE+2oLkHBIEiO4NleTIym5X+4ptalPjYvO1fDJxylchY/HSh+m 4MZvfazjkJwPis6HfjnjnkfC6ryQDMV2Oobv5FqAF8lZO80F0aH7r33UGc9cnPFy0C0F 4cQCG+9kNIgVC2NXyISf4/Ytk0tmVIii7wO1vjLP6SvAUJbUthgMMuMBhHKuEMIW3GX/ +n7J02604LIbehN47mJfpG1bUDqF8U1NdvGcXjP1JPkxhiNAKukheNFrAyle8IF6ERjq jvvwBmyfagq6heeXc0prasEMrcdoqkZGfmlewSGN9ANcRuZVnDXGFCKMeTB34LhFiO33 Gyug== X-Gm-Message-State: AOAM533kRA8FE5W2NXYzGqTUSxi0Nrkd+jzivrQr6/YY2/kjZSE6RUru xuP2dxb5r8AWv9QHHYL+p3NBrVnj8hq/ew== X-Google-Smtp-Source: ABdhPJwqtQzhO5qWfm0e3Ti2dIqFQLurzp/uEhFE28Hq7MVrMVWgmpZc7+1vWXO2IQK77wmBEOg62w== X-Received: by 2002:a05:600c:3514:b0:39c:50d2:d262 with SMTP id h20-20020a05600c351400b0039c50d2d262mr27765wmq.141.1654724937659; Wed, 08 Jun 2022 14:48:57 -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 l14-20020a05600c2cce00b0039751bb8c62sm32123664wmc.24.2022.06.08.14.48.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Jun 2022 14:48:56 -0700 (PDT) Message-ID: Date: Wed, 8 Jun 2022 22:48:55 +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: [PATCH v2] aarch64: Add fallback if ARM_CC_FOR_TARGET not set (was: Re: [PATCH 5/5] gdb: native target invalid architecture detection) Content-Language: en-US To: John Baldwin , Luis Machado , Andrew Burgess , 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> <22be6164-79d7-c0f7-1b1b-c633be452e81@palves.net> <755636d3-b2b5-9eeb-1b23-6f9830e3edbb@palves.net> <5528f112-1674-0f37-7a80-a77db8d1a31c@FreeBSD.org> From: Pedro Alves In-Reply-To: <5528f112-1674-0f37-7a80-a77db8d1a31c@FreeBSD.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.6 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=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 21:49:00 -0000 On 2022-06-08 20:01, John Baldwin wrote: >> This commit adds a fallback.  If ARM_CC_FOR_TARGET is not set, and >> testing for Linux, try arm-linux-gnueabi-gcc, >> arm-none-linux-gnueabi-gcc, arm-linux-gnueabihf-gcc as 32-bit >> compilers, making sure that the produced executable runs on the target >> machine before claiming that the compiler produces useful executables. > > Note that if the target compiler is clang, it will probably already > support 32-bit ARM via a -target option.  Not sure if you want to try > to handle that case here as well? Sure, why not. Do these multi-arch tests work on FreeBSD? At least gdb.multi/multi-arch.exp should, since FreeBSD supports multi-process nowadays, right? > > The other wrinkle perhaps is that just because you have a capable > compiler around may not mean that you have 32-bit libraries available > to link against?  I'm not sure if the compilers you list in your patch > ensure that you have an ARM libc around as well via dependencies. > That is exactly the same as on x86-64. Just because you have gcc installed, which can compile 32-bit x86 with "gcc -m32", it doesn't mean you have the 32-bit runtime libs installed. So any test using -m32 today may run into that issue already. However, note the new arm_cc_for_target proc compiles/links AND tries to run the resulting program. If there's some basic 32-bit runtime dependency missing, then the probing program won't run successfully, and we'll try the next compiler in the list of potential compilers. If we run out of compilers, then the proc returns "" and the testcase that calls arm_cc_for_target ends up bailing out with UNSUPPORTED, like so: . if {[arm_cc_for_target] != ""} { lappend options "compiler=[arm_cc_for_target]" } else { unsupported "ARM compiler is not known" return -1 } On the aarch64 ubuntu 18.04 machine on the compile farm, the first probed compiler (arm-linux-gnueabi-gcc) compiles&links successfully, but then running the built probe program fails. The second alternative doesn't exist on the system (arm-none-linux-gnueabi-gcc), so it's skipped, and then the last alternative (arm-linux-gnueabihf-gcc) compiles&links&runs the probe program successfully, so that's then the compiler that is used by the actual testcases.