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.
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?
>
> 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
>
--
宋方睿