svn commit: r364761 - in head: share/mk sys/conf sys/modules/cloudabi32 sys/modules/cloudabi64 sys/modules/linux sys/modules/linux64
Ryan Libby
rlibby at freebsd.org
Mon Dec 14 21:23:16 UTC 2020
On Mon, Dec 14, 2020 at 2:33 AM Alexander Richardson
<arichardson at freebsd.org> wrote:
>
> On Sun, 13 Dec 2020 at 19:22, Ryan Libby <rlibby at freebsd.org> wrote:
> >
> > On Tue, Aug 25, 2020 at 6:30 AM Alex Richardson <arichardson at freebsd.org> wrote:
> > >
> > > Author: arichardson
> > > Date: Tue Aug 25 13:30:03 2020
> > > New Revision: 364761
> > > URL: https://svnweb.freebsd.org/changeset/base/364761
> > >
> > > Log:
> > > Pass -fuse-ld=/path/to/ld if ${LD} != "ld"
> > >
> > > This is needed so that setting LD/XLD is not ignored when linking with $CC
> > > instead of directly using $LD. Currently only clang accepts an absolute
> > > path for -fuse-ld= (Clang 12+ will add a new --ld-path flag), so we now
> > > warn when building with GCC and $LD != "ld" since that might result in the
> > > wrong linker being used.
> > >
> > > We have been setting XLD=/path/to/cheri/ld.lld in CheriBSD for a long time and
> > > used a similar version of this patch to avoid linking with /usr/bin/ld.
> > > This change is also required when building FreeBSD on an Ubuntu with Clang:
> > > In that case we set XCC=/usr/lib/llvm-10/bin/clang and since
> > > /usr/lib/llvm-10/bin/ does not contain a "ld" binary the build fails with
> > > `clang: error: unable to execute command: Executable "ld" doesn't exist!`
> > > unless we pass -fuse-ld=/usr/lib/llvm-10/bin/ld.lld.
> > >
> > > This change passes -fuse-ld instead of copying ${XLD} to WOLRDTMP/bin/ld
> > > since then we would have to ensure that this file does not exist while
> > > building the bootstrap tools. The cross-linker might not be compatible with
> > > the host linker (e.g. when building on macos: host-linker= Mach-O /usr/bin/ld,
> > > cross-linker=LLVM ld.lld).
> > >
> > > Reviewed By: brooks, emaste
> > > Differential Revision: https://reviews.freebsd.org/D26055
> > >
> > > Modified:
> > > head/share/mk/bsd.sys.mk
> > > head/sys/conf/kern.mk
> > > head/sys/conf/kern.post.mk
> > > head/sys/modules/cloudabi32/Makefile
> > > head/sys/modules/cloudabi64/Makefile
> > > head/sys/modules/linux/Makefile
> > > head/sys/modules/linux64/Makefile
> > >
> > > Modified: head/share/mk/bsd.sys.mk
> > > ==============================================================================
> > > --- head/share/mk/bsd.sys.mk Tue Aug 25 13:29:57 2020 (r364760)
> > > +++ head/share/mk/bsd.sys.mk Tue Aug 25 13:30:03 2020 (r364761)
> > > @@ -284,6 +284,19 @@ CFLAGS+= ERROR-tried-to-rebuild-during-make-install
> > > .endif
> > > .endif
> > >
> > > +# Please keep this if in sync with kern.mk
> > > +.if ${LD} != "ld" && (${CC:[1]:H} != ${LD:[1]:H} || ${LD:[1]:T} != "ld")
> > > +# Add -fuse-ld=${LD} if $LD is in a different directory or not called "ld".
> > > +# Note: Clang 12+ will prefer --ld-path= over -fuse-ld=.
> > > +.if ${COMPILER_TYPE} == "clang"
> > > +LDFLAGS+= -fuse-ld=${LD:[1]}
> > > +.else
> > > +# GCC does not support an absolute path for -fuse-ld so we just print this
> > > +# warning instead and let the user add the required symlinks.
> > > +.warning LD (${LD}) is not the default linker for ${CC} but -fuse-ld= is not supported
> >
> > FYI: This causes a huge amount of wrong and irrelevant warnings in the
> > build log for gcc cross compilers with XLD set, such as the toolchain
> > from pkg install amd64-xtoolchain-gcc. That causes XLD to be set (via
> > CROSS_BINUTILS_PREFIX in Makefile.inc1) to a path which is indeed the
> > default linker for the cross compiler. The warnings are harmless, but
> > annoying. Sorry, I don't have a suggestion for a better method.
> >
> > You can see an example in the build log from a gcc build in CI here
> > (although note that the build currently fails for unrelated reasons):
> > https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/3131
> >
> Hi Ryan,
>
> I think there are (at least) 3 options to fix/silence this warning:
>
> 1) The easiest option would be to turn off this warning for GCC builds
> and hope that the user-supplied LD matches the one that GCC will
> invoke.
>
Thanks for looking at it. I don't have a strong feeling about it, but I
think simple is good so I'm also fine with (1).
> 2) Another option could be to ask GCC for what it thinks the default
> linker is and use that in the toolchain file, and update the check to
> use `${CC} --print-prog-name ld` instead of (${CC:[1]:H} !=
> ${LD:[1]:H} || ${LD:[1]:T} != "ld")
> $ /usr/local/bin/mips-unknown-freebsd12.1-gcc6 --print-prog-name ld
> /usr/local/bin/mips-unknown-freebsd12.1-ld
> $ /usr/local/bin/mips-unknown-freebsd12.1-gcc6 --print-prog-name ld.bfd
> /usr/local/lib/gcc/mips-unknown-freebsd12.1/6.5.0/../../../../mips-unknown-freebsd12.1/bin/ld.bfd
>
Examining this, in amd64-xtoolchain-gcc:
XCC=/usr/local/bin/x86_64-unknown-freebsd13.0-gcc
...
CROSS_BINUTILS_PREFIX=/usr/local/x86_64-unknown-freebsd13.0/bin/
...
but
% /usr/local/bin/x86_64-unknown-freebsd13.0-gcc --print-prog-name=ld
/usr/local/bin/x86_64-unknown-freebsd13.0-ld
% /usr/local/bin/x86_64-unknown-freebsd13.0-gcc
--sysroot=/usr/obj/gcc6/usr/src/freebsd/amd64.amd64/tmp
-B/usr/local/x86_64-unknown-freebsd13.0/bin/ --print-prog-name=ld
/usr/local/bin/x86_64-unknown-freebsd13.0-ld
So I was not exactly correct, above. They're hard links to the same ld
program, but through different paths (even with -B as it appears in the
build).
I'm assuming this is okay but now I wonder if the xtoolchain is slightly
misconfigured, or if gcc is lying (it's not reporting the path from
-B)...
...okay, examining ports/devel/freebsd-gcc6/Makefile:
--with-ld=${LOCALBASE}/bin/${BU_PREFIX}-ld
So the xtoolchain gcc linker can't be influenced with -B. Hmm. It
seems wrong that XCC's default linker path is different from XLD, even
if they are links to the same file.
Anyway, all that is to say, I think that this sounds good in concept but
may also need either a fix in the xtoolchain or more hackery in the
make files.
> 2a) We could also use ${CC} -xc /dev/null -o /dev/null -Wl,--version`
> to detect linker features in bsd.linker.mk and check if that matches
> the value returned by ${LD} --version.
>
> 3) Change the xtoolchain installed a gcc-N hardlink in
> /usr/local/<arch>-unknown-freebsd<version>/bin and use that as ${CC}.
> It would match then the ld directory and the existing check could
> work.
This seems okay to me but it sounds like a big change for a warning, and
anyway I think (2) is probably a more reliable method of determining the
default linker. It would seem to make some sense for a toolchain to
have a whole directory with links to all the tools. However I'm not an
expert here.
>
> I'd personally opt for 1 since I don't build with GCC and don't have
> time right now to implement the other options.
> Let me know what you think.
>
> Thanks,
> Alex
(CC'd jhb in case he has an opinion on the xtoolchain --with-ld vs XLD bit.)
Thanks,
Ryan
>
> > > +.endif
> > > +.endif
> > > +
> > > # Tell bmake not to mistake standard targets for things to be searched for
> > > # or expect to ever be up-to-date.
> > > PHONY_NOTMAIN = analyze afterdepend afterinstall all beforedepend beforeinstall \
> > >
> > > Modified: head/sys/conf/kern.mk
> > > ==============================================================================
> > > --- head/sys/conf/kern.mk Tue Aug 25 13:29:57 2020 (r364760)
> > > +++ head/sys/conf/kern.mk Tue Aug 25 13:30:03 2020 (r364761)
> > > @@ -270,6 +270,22 @@ CFLAGS+= -std=iso9899:1999
> > > CFLAGS+= -std=${CSTD}
> > > .endif # CSTD
> > >
> > > +# Please keep this if in sync with bsd.sys.mk
> > > +.if ${LD} != "ld" && (${CC:[1]:H} != ${LD:[1]:H} || ${LD:[1]:T} != "ld")
> > > +# Add -fuse-ld=${LD} if $LD is in a different directory or not called "ld".
> > > +# Note: Clang 12+ will prefer --ld-path= over -fuse-ld=.
> > > +.if ${COMPILER_TYPE} == "clang"
> > > +# Note: unlike bsd.sys.mk we can't use LDFLAGS here since that is used for the
> > > +# flags required when linking the kernel. We don't need those flags when
> > > +# building the vdsos. However, we do need -fuse-ld, so use ${CCLDFLAGS} instead.
> > > +CCLDFLAGS+= -fuse-ld=${LD:[1]}
> > > +.else
> > > +# GCC does not support an absolute path for -fuse-ld so we just print this
> > > +# warning instead and let the user add the required symlinks.
> > > +.warning LD (${LD}) is not the default linker for ${CC} but -fuse-ld= is not supported
> > > +.endif
> > > +.endif
> > > +
> > > # Set target-specific linker emulation name.
> > > LD_EMULATION_aarch64=aarch64elf
> > > LD_EMULATION_amd64=elf_x86_64_fbsd
> > >
> > > Modified: head/sys/conf/kern.post.mk
> > > ==============================================================================
> > > --- head/sys/conf/kern.post.mk Tue Aug 25 13:29:57 2020 (r364760)
> > > +++ head/sys/conf/kern.post.mk Tue Aug 25 13:30:03 2020 (r364761)
> > > @@ -228,7 +228,7 @@ kernel-clean:
> > > # in the a.out ld. For now, this works.
> > > hack.pico: Makefile
> > > :> hack.c
> > > - ${CC} -shared ${CFLAGS} -nostdlib hack.c -o hack.pico
> > > + ${CC} ${CCLDFLAGS} -shared ${CFLAGS} -nostdlib hack.c -o hack.pico
> > > rm -f hack.c
> > >
> > > offset.inc: $S/kern/genoffset.sh genoffset.o
> > >
> > > Modified: head/sys/modules/cloudabi32/Makefile
> > > ==============================================================================
> > > --- head/sys/modules/cloudabi32/Makefile Tue Aug 25 13:29:57 2020 (r364760)
> > > +++ head/sys/modules/cloudabi32/Makefile Tue Aug 25 13:30:03 2020 (r364761)
> > > @@ -33,7 +33,7 @@ BINARY_ARCHITECTURE=i386
> > > .endif
> > >
> > > cloudabi32_vdso.o: ${VDSO_SRCS}
> > > - ${CC} -x assembler-with-cpp -m32 -shared -nostdinc -nostdlib \
> > > + ${CC} ${CCLDFLAGS} -x assembler-with-cpp -m32 -shared -nostdinc -nostdlib \
> > > -Wl,-T${SYSDIR}/compat/cloudabi/cloudabi_vdso.lds \
> > > ${VDSO_SRCS} -o ${.TARGET}
> > >
> > >
> > > Modified: head/sys/modules/cloudabi64/Makefile
> > > ==============================================================================
> > > --- head/sys/modules/cloudabi64/Makefile Tue Aug 25 13:29:57 2020 (r364760)
> > > +++ head/sys/modules/cloudabi64/Makefile Tue Aug 25 13:30:03 2020 (r364761)
> > > @@ -25,7 +25,7 @@ BINARY_ARCHITECTURE=i386
> > > .endif
> > >
> > > cloudabi64_vdso.o: ${VDSO_SRCS}
> > > - ${CC} -x assembler-with-cpp -shared -nostdinc -nostdlib \
> > > + ${CC} ${CCLDFLAGS} -x assembler-with-cpp -shared -nostdinc -nostdlib \
> > > -Wl,-T${SYSDIR}/compat/cloudabi/cloudabi_vdso.lds \
> > > ${VDSO_SRCS} -o ${.TARGET}
> > >
> > >
> > > Modified: head/sys/modules/linux/Makefile
> > > ==============================================================================
> > > --- head/sys/modules/linux/Makefile Tue Aug 25 13:29:57 2020 (r364760)
> > > +++ head/sys/modules/linux/Makefile Tue Aug 25 13:30:03 2020 (r364761)
> > > @@ -54,7 +54,7 @@ linux${SFX}_assym.h: linux${SFX}_genassym.o
> > > sh ${SYSDIR}/kern/genassym.sh linux${SFX}_genassym.o > ${.TARGET}
> > >
> > > linux${SFX}_locore.o: linux${SFX}_assym.h assym.inc
> > > - ${CC} -x assembler-with-cpp -DLOCORE -m32 -shared -s \
> > > + ${CC} ${CCLDFLAGS} -x assembler-with-cpp -DLOCORE -m32 -shared -s \
> > > -pipe -I. -I${SYSDIR} ${WERROR} -Wall -fno-common -nostdinc -nostdlib \
> > > -fno-omit-frame-pointer -fPIC \
> > > -Wl,-T${SRCTOP}/sys/${MACHINE_CPUARCH}/linux${SFX}/${VDSO}.lds.s \
> > >
> > > Modified: head/sys/modules/linux64/Makefile
> > > ==============================================================================
> > > --- head/sys/modules/linux64/Makefile Tue Aug 25 13:29:57 2020 (r364760)
> > > +++ head/sys/modules/linux64/Makefile Tue Aug 25 13:30:03 2020 (r364761)
> > > @@ -30,7 +30,7 @@ linux_assym.h: linux_genassym.o
> > > sh ${SYSDIR}/kern/genassym.sh linux_genassym.o > ${.TARGET}
> > >
> > > linux_locore.o: linux_locore.asm linux_assym.h
> > > - ${CC} -x assembler-with-cpp -DLOCORE -shared -mcmodel=small \
> > > + ${CC} ${CCLDFLAGS} -x assembler-with-cpp -DLOCORE -shared -mcmodel=small \
> > > -pipe -I. -I${SYSDIR} ${WERROR} -Wall -fno-common -fPIC -nostdinc \
> > > -Wl,-T${SRCTOP}/sys/${MACHINE}/linux/${VDSO}.lds.s \
> > > -Wl,-soname=${VDSO}.so.1,-warn-common -nostdlib \
More information about the svn-src-head
mailing list