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.
Most of the time this goes unnoticed because the host linker is new
enough to work anyway, but this cannot be reliably assumed.
Extract the needed --target and --gcc-toolchain flags added in the top
level Makefile from KBUILD_CFLAGS. These flags direct clang to the
appropriate toolchain to link the vdsos.
Cc: Andy Lutomirski <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Alistair Strachan <[email protected]>
---
arch/x86/entry/vdso/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index 261802b1cc50..062ee94d2d26 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -163,7 +163,8 @@ quiet_cmd_vdso = VDSO $@
sh $(srctree)/$(src)/checkundef.sh '$(NM)' '$@'
VDSO_LDFLAGS = -fPIC -shared $(call cc-ldoption, -Wl$(comma)--hash-style=both) \
- $(call cc-ldoption, -Wl$(comma)--build-id) -Wl,-Bsymbolic $(LTO_CFLAGS)
+ $(call cc-ldoption, -Wl$(comma)--build-id) -Wl,-Bsymbolic $(LTO_CFLAGS) \
+ $(filter --target=% --gcc-toolchain=%,$(KBUILD_CFLAGS))
GCOV_PROFILE := n
#
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?
-hpa
On Thu, Jul 12, 2018 at 1:25 PM H. Peter Anvin <[email protected]> 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.
On 07/12/18 13:37, Alistair Strachan wrote:
> On Thu, Jul 12, 2018 at 1:25 PM H. Peter Anvin <[email protected]> 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.
-hpa
> On Jul 12, 2018, at 3:06 PM, H. Peter Anvin <[email protected]> wrote:
>
>> On 07/12/18 13:37, Alistair Strachan wrote:
>>> On Thu, Jul 12, 2018 at 1:25 PM H. Peter Anvin <[email protected]> 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
On Thu, Jul 12, 2018 at 4:20 PM Andy Lutomirski <[email protected]> wrote:
>
> > On Jul 12, 2018, at 3:06 PM, H. Peter Anvin <[email protected]> wrote:
> >
> >> On 07/12/18 13:37, Alistair Strachan wrote:
> >>> On Thu, Jul 12, 2018 at 1:25 PM H. Peter Anvin <[email protected]> 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)?
I'm guessing, but I think this wasn't done originally because CC is
something the user might reasonably specify on the command line (the
other bit comes from CROSS_COMPILE), so doing this via CC would
require us to override the CC passed in on the command line. Not sure
how to do that, since the vdso makefile is executed with a submake, so
the usual "override CC := $(CC) something else" followed by "export
CC" doesn't work.