Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20180712201032.156997-1-astrachan@google.com> <47d4b24e-8c60-fb3b-3377-62d20c5f3dd1@zytor.com>
 <CANDihLEz3_fZ4r4g=VcxWps5DWSjMJdbJZKZWsLFKVp_c7FscA@mail.gmail.com>
 <1432bfde-41b4-e8aa-037b-fca41a149cb8@zytor.com> <5AB78E47-BC62-4DA5-920B-00E9731AAE04@amacapital.net>
In-Reply-To: <5AB78E47-BC62-4DA5-920B-00E9731AAE04@amacapital.net>
From:   Alistair Strachan <astrachan@google.com>
Date:   Thu, 12 Jul 2018 17:01:06 -0700
Message-ID: <CANDihLFWXKd1ijdTFCdZSa4yiQLMP=PhUpws41DYfOP-zLOpng@mail.gmail.com>
Subject: Re: [PATCH] x86: vdso: Fix leaky vdso link with CC=clang
To:     luto@amacapital.net
Cc:     hpa@zytor.com, linux-kernel@vger.kernel.org, luto@kernel.org,
        tglx@linutronix.de, mingo@redhat.com,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        x86@kernel.org, kernel-team@android.com, joel@joelfernandes.com
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Jul 12, 2018 at 4:20 PM Andy Lutomirski <luto@amacapital.net> wrote:
>
> > On Jul 12, 2018, at 3:06 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> >
> >> On 07/12/18 13:37, Alistair Strachan wrote:
> >>> On Thu, Jul 12, 2018 at 1:25 PM H. Peter Anvin <hpa@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)?

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.