> On Jul 12, 2018, at 3:06 PM, H. Peter Anvin <h...@zytor.com> wrote: > >> On 07/12/18 13:37, Alistair Strachan wrote: >>> On Thu, Jul 12, 2018 at 1:25 PM H. Peter Anvin <h...@zytor.com> wrote: >>>> On 07/12/18 13:10, Alistair Strachan wrote: >>>> The vdso{32,64}.so can fail to link with CC=clang when clang tries to >>>> find a suitable GCC toolchain to link these libraries with. >>>> >>>> /usr/bin/ld: arch/x86/entry/vdso/vclock_gettime.o: >>>> access beyond end of merged section (782) >>>> >>>> This happens because the host environment leaked into the cross >>>> compiler environment due to the way clang searches for suitable GCC >>>> toolchains. >>>> >>> >>> Is this another clang bug that you want a workaround for in the kernel? >> >> Clang is a retargetable compiler (specified with --target=<something>) >> and so it has a mechanism for searching for suitable binutils (from >> another "GCC toolchain") to perform assembly and linkage. This >> mechanism relies on both --target and --gcc-toolchain when >> cross-compiling, otherwise it will fall back to searching /usr. >> >> The --target and --gcc-toolchain flags are already specified correctly >> in the top level Makefile, but the vdso Makefile rolls its own linker >> flags and doesn't use KBUILD_CFLAGS. Therefore, these flags get >> incorrectly dropped from the vdso $CC link command line, and an >> inconsistency is created between the "GCC toolchain" used to generate >> the objects for the vdso, and the linker used to link them. >> > > It sounds like there needs to be a more fundamental symbol than > KBUILD_CFLAGS to contain these kinds of things.
How about $(CC)? > > -hpa