From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) by sourceware.org (Postfix) with ESMTPS id DFA8C3858D37 for ; Thu, 14 Jul 2022 20:41:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DFA8C3858D37 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-pf1-x42e.google.com with SMTP id w185so2894458pfb.4 for ; Thu, 14 Jul 2022 13:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; h=date:subject:in-reply-to:cc:from:to:message-id:mime-version :content-transfer-encoding; bh=pDvrxfxL0qe6KY2apohROLXncOK30iEV/SxgjEY9yHo=; b=d8ezetkCc33m23Be4FB/nIvpU8A4pgUUSuShLx1y2Unr6zmsLdP0lGvTNVlYlH1beR bTsUf1cgXZCAOORMrQLrRlWv+h83TVxNSV5Huu9KPyYKEwG1BLblhEm2MCaLWtdINI98 Ez6nX7thtLg1IVQZHgT6+F3/2tRZsKZWpdD162aMjuWKOVkumtYEvsdEgwPboyN8F7UP KKCuS65rETXn4WCJOeckgpIo0wCg+HKnVzNjarlGeuKczXU0tsRw0EUHR7rdiS2Jdj3i 8dpO3WMScJ/dDG9ZfHG4ILPjv+SsOC7QEk9ZvhbwDyRWad0+5bAnqvkUn2UUder8xNem e9Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=pDvrxfxL0qe6KY2apohROLXncOK30iEV/SxgjEY9yHo=; b=ucjMXZvnAUE9aU5T7yfU0+C39vJcsFkO7npC28Cxc7yxfZ82jipoDMLo/A+jIi80AI +Mm21wuHD9RBX2eOYpqaT0aqNX3+drIQLztCJueMDz5Yyhq+TSbusifJWV2HUvOfr38g f0FbJjP39bYzMMvzhy/PL09uD8vHqvA+/4XuODFnUNuuruWFGkFV0Dg6WIQ0nxiQ9xJx OuE3hrvvm/6yoIUV1qejxWZxX93Lyvz7rNI2rXs/bDW2kvbTdZ7ltNo7M2o5Ckn7ny3n 3MGqvpURzc2zYoadnxrd6qZ0tiXgpz65YJ/kCvBolaL3nPYoh3c9DcdxS/6Tl6P1pgO6 I+Pg== X-Gm-Message-State: AJIora92r/ADet2zSU030GMH/FU75tYy/Mg0k84gBCgpJCL1NST7O5dX Oq7TpefO2Z6KO04KEng6xBrkLA== X-Google-Smtp-Source: AGRyM1uvNCGkQr693xGn7H/v08reH1yxDN54zKuv478vKpHlvpwARvGBO1+Kk+Hembn5WSYJa9huPg== X-Received: by 2002:a05:6a00:158d:b0:52b:18a4:c73a with SMTP id u13-20020a056a00158d00b0052b18a4c73amr6285500pfk.51.1657831292771; Thu, 14 Jul 2022 13:41:32 -0700 (PDT) Received: from localhost ([50.221.140.186]) by smtp.gmail.com with ESMTPSA id f12-20020a63f10c000000b0040c52ff0ba9sm1825730pgi.37.2022.07.14.13.41.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Jul 2022 13:41:32 -0700 (PDT) Date: Thu, 14 Jul 2022 13:41:32 -0700 (PDT) X-Google-Original-Date: Thu, 14 Jul 2022 13:41:26 PDT (-0700) Subject: Re: [PATCH] Revert "[PATCH] RISC-V: Use new linker emulations for glibc ABI." In-Reply-To: CC: Kito Cheng , jrtc27@jrtc27.com, kito.cheng@sifive.com, gcc-patches@gcc.gnu.org, Nelson Chu From: Palmer Dabbelt To: gcc-patches@gcc.gnu.org Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-11.3 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, 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: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2022 20:41:36 -0000 On Mon, 20 Jun 2022 20:48:50 PDT (-0700), gcc-patches@gcc.gnu.org wrote: > On Mon, Jun 20, 2022 at 1:21 AM Kito Cheng wrote: >> >> Generally I agree we should fix that by GCC driver rather than ld >> emulation, but I think this should be reverted with the -L path fix, >> otherwise that will break multilib on GNU toolchain for linux >> immediately? IIUC just changing this will break even non-multlib systems, though it's possible that the symlinks work around that sufficiently. > Thanks for the good consideration. That said, I am unsure any distro > uses this currently. > I think some just work around the possibly non-existent paths by > creating symlinks. > Perhaps we should prioritize on fixing the scheme before distros start > to rely on the behavior. I'm kind of torn on this one: this has been around for a while and dropping it would be an ABI break, but the feedback from distro folks is pretty consistently that multlib is broken on RISC-V. If it's really unusably broken then I could buy the argument that there's no binaries (and thus no ABI to break), but there's at some base multilib functionality working -- I build multilib cross toolchains regularly, for example, and they can build simple stuff. I always find making that "nobody's used it" argument really hard, there's just too many users to try and track everyone down. We're in kind of a weird spot with RISC-V in general when it comes to ABI stuff: we were probably a bit overly optimistic about how fast any of this was going to get used when we committed to the ABI freeze, but any ABi break has such a huge potential for user headaches that I'm not sure it's going to be possible. It means we're stuck with some baggage, and while it's a headache to keep around stuff that's probably not all that useful I think it's just what we've got to live with. If multlib really is so broken it's not fixable without an ABI break then I guess there's no other option, but I think in this case we have some: One option would be to add an ld argument that says to turn off the emulation-specific path resolution, which we could then add to LINK_SPEC when we get the library paths sorted out? We'd still have the emulations and the subdirs, but at least we wouldn't need a flag day. Another option would be to add new multlib paths that don't have the subdirectories, as last I checked that was an issue for distros (violates FHS, breaks build systems, etc). If we're going to do that anyway then we could piggyback the new behavior on it and deprecate the old paths along with whatever behavior is associated with them. >> On Wed, Jun 15, 2022 at 4:00 PM Fangrui Song via Gcc-patches >> wrote: >> > >> > This reverts commit 37d57ac9a636f2235f9060e84fb8dd7968abd1dc. >> > >> > The resolution to https://sourceware.org/bugzilla/show_bug.cgi?id=22962 >> > let GCC pass -m emulation to ld and let the ld emulation configure >> > default library paths. This scheme is problematic: >> > >> > * It's not ld's business to specify default -L. Different platforms have >> > different opinions on the hierarchy and all other arches work well without ld's >> > default -L. >> > * If some ABI derived library paths are desired, the compiler driver is in a >> > better position to make the decision and traditionally has done this. >> > * -m emulation is opaque to the compiler driver. It doesn't affect -B, so >> > data files like crt*.o, libasan_preinit.o, and libtsan_preinit.o are not affected. >> > >> > As is, many platforms just use symlinks to fake the lib64/{ilp32{,f},lp64{,f}} >> > hierarchies needed by the GNU ld emulation. They can always specify -L >> > explicitly if they want some ABI derived library paths. See also the rejected >> > https://reviews.llvm.org/D95755 I don't do a lot of LLVM stuff, but that has a green check mark that says "accepted" at the top. Does that mean it was merged somewhere, or just that it was acked/reviewed and then dropped? >> > >> > gcc/Changelog: >> > >> > * config/riscv/linux.h (LD_EMUL_SUFFIX): Remove. >> > (LINK_SPEC): Remove LD_EMUL_SUFFIX. >> > --- >> > gcc/config/riscv/linux.h | 10 +--------- >> > 1 file changed, 1 insertion(+), 9 deletions(-) >> > >> > diff --git a/gcc/config/riscv/linux.h b/gcc/config/riscv/linux.h >> > index 38803723ba9..e0ff6e6a178 100644 >> > --- a/gcc/config/riscv/linux.h >> > +++ b/gcc/config/riscv/linux.h >> > @@ -49,16 +49,8 @@ along with GCC; see the file COPYING3. If not see >> > >> > #define CPP_SPEC "%{pthread:-D_REENTRANT}" >> > >> > -#define LD_EMUL_SUFFIX \ >> > - "%{mabi=lp64d:}" \ >> > - "%{mabi=lp64f:_lp64f}" \ >> > - "%{mabi=lp64:_lp64}" \ >> > - "%{mabi=ilp32d:}" \ >> > - "%{mabi=ilp32f:_ilp32f}" \ >> > - "%{mabi=ilp32:_ilp32}" >> > - >> > #define LINK_SPEC "\ >> > --melf" XLEN_SPEC DEFAULT_ENDIAN_SPEC "riscv" LD_EMUL_SUFFIX " \ >> > +-melf" XLEN_SPEC DEFAULT_ENDIAN_SPEC "riscv \ >> > %{mno-relax:--no-relax} \ >> > %{mbig-endian:-EB} \ >> > %{mlittle-endian:-EL} \ >> > -- >> > 2.36.1.476.g0c4daa206d-goog >> > > > > > -- > 宋方睿