On 2022-07-14, Palmer Dabbelt wrote:
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 <kito.ch...@gmail.com> 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.
Thanks for chiming in and providing the good consideration. I don't do
much GNU development. I just spotted something and think it should be
fixed. If dropping -L is considered a risk, an alternative scheme is
that someone:
* create an alternative patch making GCC driver pass the -L to ld and use the
plain emulation name.
* a configure option can possibly be added to guard whether the -L is added at
all
* drop the excessive emulations in GNU ld.
This way an alternative linker implementation doesn't have to add a
compatibility no-op option.
I appreciate anyone who wants to step up and helps removing
eelf64lriscv_{lp64,ilp32f,...}. We will have "*64briscv*" variants and
it will then look really ugly.
On Wed, Jun 15, 2022 at 4:00 PM Fangrui Song via Gcc-patches
<gcc-patches@gcc.gnu.org> 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?
I could land it, but I realized that would be a mistake so I stopped.
There has since been no real need for this feature, either. I wished
that some RISC-V folks stepped up and fixed it. It took so long so I
ended up sending this patch myself, but I have no bandwidth to change this
patch to a form providing better compatibility....
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
--
宋方睿
