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=-2.1 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,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 05B9A1F4C1 for ; Thu, 1 Dec 2022 00:46:06 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=rivosinc-com.20210112.gappssmtp.com header.i=@rivosinc-com.20210112.gappssmtp.com header.b="4ah6zCAj"; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C28263855146 for ; Thu, 1 Dec 2022 00:46:01 +0000 (GMT) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) by sourceware.org (Postfix) with ESMTPS id D8BEB3858D1E for ; Thu, 1 Dec 2022 00:45:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D8BEB3858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-pj1-x1033.google.com with SMTP id l22-20020a17090a3f1600b00212fbbcfb78so3649508pjc.3 for ; Wed, 30 Nov 2022 16:45:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=o1XvZ41wMVE4p5HeIJ774XYmNCb4iejFiw4/sCQkKNw=; b=4ah6zCAj8w+fWOsvq9DiZ53GC9KvHTjxa7+ilsjxdIeE1UQci5XF9DpkjXOkzNIeJs I7RwRc0h+/QC407fvzEYEhp8s8SmyXf376OMhGSuu//u4SVBFBw81uroU1E9Bss7N8Su ZqMW/ZP5uSKJYX8zZ3PB2FXp4Shif8UhvBM7iYY5hk+0EgnGa3/osFWnhNWmih946WY9 rmorVgw3SSP0Zlp831h8eKy8nbn26mzwr3doXx0MuXzlsCree+hjcfVLCAcsoeUEW5Eu JCnqxNgMcWp2/6EIyJ8ZWYjaJLFd4Cefr1Iq+uZzKlIyxE0ax+t+qhyOcqR61K7D7zgt CzjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=o1XvZ41wMVE4p5HeIJ774XYmNCb4iejFiw4/sCQkKNw=; b=7s513OgCQzsu8mnZccIZV8B5vNNJZPHxUu/nkL0JEN77s5HhPEIGfbrYXR0dONBwBB g4QXQ/5RPu3j+AJiZvkw5JXGiLkMXtDLbDo3ttU7K1KNU69rXnxBbZGHaOJxTfis0NtT mFRW0REw0ALV9PNiF6qMussEEm2xqKo4gnYiXn6smeJ6xGa6x0rtmctO4au7YH6CrQEw QGLHqXuXO/89yBm70FKTEEbdr20/qB41dG21bANem9izyqMc12GevxHrnZkoB6TfBztm Fso5wcSLgfhV+dMgrf36xcrLWYnu0Nylfe837Me269vpMr80vi2z9p2N/6PscgL+RA5R WJXw== X-Gm-Message-State: ANoB5pnNh+cdXzL0o721wXKqT4Hl75w2BVt4Q0GRNJ2iW09Uo3RqTImW djfKjJtDl7aad6DD7K5SiHlyz9PCtgdwQQ== X-Google-Smtp-Source: AA0mqf4pCIo98a8RBqhQXU2WueyXGKbS/BL3y905/FdRFnUwR4b5Hr9F4BkiCqLitVB3CNJuTZuEuA== X-Received: by 2002:a17:902:db0c:b0:189:1963:d0d7 with SMTP id m12-20020a170902db0c00b001891963d0d7mr45495715plx.100.1669855545463; Wed, 30 Nov 2022 16:45:45 -0800 (PST) Received: from [192.168.50.116] (c-24-4-73-83.hsd1.ca.comcast.net. [24.4.73.83]) by smtp.gmail.com with ESMTPSA id x27-20020aa7957b000000b0057534fcd895sm1950550pfq.108.2022.11.30.16.45.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Nov 2022 16:45:44 -0800 (PST) Message-ID: Date: Wed, 30 Nov 2022 16:45:42 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [PATCH] Revert "Correctly determine libc.so 'OUTPUT_FORMAT' when cross-compiling." To: Adhemerval Zanella Netto , Palmer Dabbelt Cc: libc-alpha@sourceware.org, carlos@redhat.com, maskray@google.com, ludo@gnu.org, nelson@rivosinc.com, gnu-toolchain@rivosinc.com References: Content-Language: en-US From: Vineet Gupta In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed 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: , Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On 11/30/22 04:39, Adhemerval Zanella Netto wrote: > > 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. Certainly the ability to override OBJDUMP (actually all of binutils) seems useful. However the issue with the original patch was it assuming that triplet prefixed binary exists and even worse it silently falling back to host binary if it fails to find one. If we really want to support the original patch, it should add a fallback of using $CC -print-prog-name if the triplet binary search fails. But as it stands, riscv multilib toolchain builds are currently hosed because of this. -Vineet > 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/