From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-3.4 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,NICE_REPLY_A, PDS_RDNS_DYNAMIC_FP,RCVD_IN_DNSWL_HI,RDNS_DYNAMIC,SPF_HELO_PASS, SPF_PASS,URIBL_BLACK shortcircuit=no autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 1B0C81F4C1 for ; Wed, 30 Nov 2022 12:39:51 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b="j06muW1j"; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 239873858C3A for ; Wed, 30 Nov 2022 12:39:49 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 239873858C3A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1669811989; bh=qN8Gvx94bzKBFafLBGvVJuOPyHx0MPhZantx6G7MkqE=; h=Date:Subject:To:Cc:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=j06muW1j/tmD5XHMmKSJ/U+PhEq9KAMpRF8FChdhu9XXq4y3hpBBm4LUQ0vv/JWDO fJXCFNdZrk7bz+ZerxJGueVTCYGAVGS7ok4I/hFlXD5VbaOCf0bp9pE6e0jILkkvmy 5BBHNtOx1b+IcpVwtnSoGDYFONOoUcv4M44IZApE= Received: from mail-oa1-x2a.google.com (mail-oa1-x2a.google.com [IPv6:2001:4860:4864:20::2a]) by sourceware.org (Postfix) with ESMTPS id A16D83858D1E for ; Wed, 30 Nov 2022 12:39:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A16D83858D1E Received: by mail-oa1-x2a.google.com with SMTP id 586e51a60fabf-1433ef3b61fso20762664fac.10 for ; Wed, 30 Nov 2022 04:39:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qN8Gvx94bzKBFafLBGvVJuOPyHx0MPhZantx6G7MkqE=; b=Wa4NKVMzBEI+VQUi36oXinLdAw5U/yIuo1CycwLBBPsLzHM0CRKFvaGH62xFwQOazo xnHNbZ5dAksp5mEvvBydlDQT4JDWmlRUVrXKHGYewIQE7RKjN9NzN0uPHDbe/OvKP+hP O8kW/5LR9NA0AVe2yVE6B8l1qFhRv6hdv4/FI2JtTFKgrtgvlCTTXKDdRlYtnPPtyXiU ty0LEAFTNzmqAb9hYy3bFG0kwEFOlF7TvnqNVYvd2f1Zc6UExJ5gF4AM34IScFucjCfC TeCTS7sAWBdNa+qmizrLKJjaGU4pWAH2qNqPy/4g3aGajtFKDLIk4/r04G9fRjm1QPFO Vicg== X-Gm-Message-State: ANoB5pkS03DkwNl7eUjoJJ3er7xON9Pb2lSS4n2JS3NdAcAOkTDt6+kP hAbJ4ck40gHBP1yTJ0fMOioXFw== X-Google-Smtp-Source: AA0mqf6Ee2bjCJPH1WJ1kTos43dJMNZe+eGdKL4OnLtmhaoC3Ul+M7cr5E8f/ZjmR+5XwKD/9upSzw== X-Received: by 2002:a05:6870:9f0c:b0:13c:97e9:5d40 with SMTP id xl12-20020a0568709f0c00b0013c97e95d40mr24213602oab.42.1669811968168; Wed, 30 Nov 2022 04:39:28 -0800 (PST) Received: from ?IPV6:2804:1b3:a7c1:f215:2982:53e8:7f84:95db? ([2804:1b3:a7c1:f215:2982:53e8:7f84:95db]) by smtp.gmail.com with ESMTPSA id s131-20020acac289000000b003539686cb7bsm536628oif.53.2022.11.30.04.39.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Nov 2022 04:39:27 -0800 (PST) Message-ID: Date: Wed, 30 Nov 2022 09:39:24 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH] Revert "Correctly determine libc.so 'OUTPUT_FORMAT' when cross-compiling." Content-Language: en-US To: Palmer Dabbelt , Vineet Gupta Cc: libc-alpha@sourceware.org, carlos@redhat.com, maskray@google.com, ludo@gnu.org, nelson@rivosinc.com, gnu-toolchain@rivosinc.com References: Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Adhemerval Zanella Netto via Libc-alpha Reply-To: Adhemerval Zanella Netto Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On 28/11/22 20:25, Palmer Dabbelt wrote: > On Tue, 22 Nov 2022 18:59:32 PST (-0800), Vineet Gupta wrote: >> This reverts commit 361d6454c034a920f2c96517c277990d390b9652. >> >> This trips up riscv gnu toolchain builds [1] >> >> riscv ld segfaults when linking libgcc because libc.so linker script >> contains `OUTPUT_FORMAT(elf32-little)` vs. `OUTPUT_FORMAT(elf32-littleriscv)`. > > Sounds like a linker bug? > >> This patch causes builds to lookup riscv32* prefixed objdump and failing >> to find it falls back to host objdump which is the root of the issue. >> The host objdump in turn generates `OUTPUT_FORMAT(elf32-little)` >> >> riscv glibc multilib builds lack riscv32 prefix binaries. They have a >> single set of "riscv64" prefixed binaries supporting both 32 and 64-bit >> abis: ilp32/ilp32d/lp64/lp64d using -march/-mabi. > > Though we _could_ have riscv32-* and riscv64-* binaries (and also riscv*- too), it just doesn't make much of a difference as the riscv64-* binaries can target everything.  If the answer here is just "fix riscv-gnu-toolchain" that seems reasonable to me, but also happy to avoid touching that so > > Acked-by: Palmer Dabbelt > > Though some sort of global reviewer should take a look here, I definately don't understand the glibc build process well enough to review this one. > I think the question is whether we need to set OBJDUMP and/or can override or if we should derive the tools solely from CC. It make sense for later, since using a different binutils than the one CC is meant to use not always guarantee that compiler will emits all supports instructions or ABI. The build-many-glibc.py sets the OBJDUMP, so I think it would be good to also remove its usage (since with this patch OBJDUMP can not be override anymore). In fact the only way to override the binutils with LIBC_PROG_BINUTILS is to use --with-binutils (which has some issues [1] though). The --with-binutils is also a developer options, so I wonder if we should simplify the build process by removing it along with LIBC_PROG_BINUTILS, and replace with a new macro that checks whether the tools is set, otherwise uses the CC with -print-prog-name for default case. It would continue to provide a way to override binutils tools (for development and testing) and simplify the build process (one less configure option). GUIX can then override OBJDUMP if it need (and it was not clear not me why CC -print-prog-name does not work on this environment). [1] https://patchwork.sourceware.org/project/glibc/patch/20221115193159.173838-2-adhemerval.zanella@linaro.org/