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: <CAG5bF+SSMTvkgnQwHC1gx0pzysXhmMJ_+hUci_SJDPSteL4BcQ@mail.gmail.com>
 <CAKwvOd=aqWvjzC1ZF5_pXx2VutAX0dneDPxU_=jroqHUGw-X6g@mail.gmail.com>
In-Reply-To: <CAKwvOd=aqWvjzC1ZF5_pXx2VutAX0dneDPxU_=jroqHUGw-X6g@mail.gmail.com>
From:   Masahiro Yamada <yamada.masahiro@socionext.com>
Date:   Wed, 20 Mar 2019 23:06:20 +0900
Message-ID: <CAK7LNAT5JkoONtDzrG6Ft6xxdYUcc5-H2CSGO_9zGsbykbE7Eg@mail.gmail.com>
Subject: Re: [PATCH] x86/vdso: include generic __lshrdi3 in 32-bit vDSO
To:     Nick Desaulniers <ndesaulniers@google.com>
Cc:     Matthias Kaehlcke <mka@chromium.org>,
        Andy Lutomirski <luto@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        "H . Peter Anvin" <hpa@zytor.com>, X86 ML <x86@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Manoj Gupta <manojgupta@chromium.org>,
        Tiancong Wang <tcwang@chromium.org>,
        Stephen Hines <srhines@google.com>,
        clang-built-linux@googlegroups.com
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sat, Mar 16, 2019 at 6:32 AM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> On Fri, Mar 15, 2019 at 12:54 PM Matthias Kaehlcke <mka@chromium.org> wrote:
> >
> > Building the 32-bit vDSO with a recent clang version fails due
> > to undefined symbols:
> >
> > arch/x86/entry/vdso/vdso32.so.dbg: undefined symbols found
> >
> > The undefined symbol in this case is __lshrdi3, which is part of
> > the compiler runtime library, however the vDSO isn't linked against
> > this library.
> >
> > Include the kernel version of __lshrdi3 in the 32-bit vDSO build.
>
> __lshrdi3 is used for "logical shift right double-word by int" (best
> guess), so anywhere there's a right shift of a u64.  Looks like
> there's a few of these in arch/x86/entry/vdso/, so it's legal for the
> compiler to emit this libcall.  Do you know which function
> specifically in the .so has a relocation referencing __lshrdi3
> specifically?
>
> Is there a config I can set to reproduce this, in order to help test?
>
> >
> > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> > ---
> >  arch/x86/entry/vdso/Makefile | 7 ++++++-
> >  lib/lshrdi3.c                | 4 +++-
> >  2 files changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
> > index 5bfe2243a08f..7517cd87e10b 100644
> > --- a/arch/x86/entry/vdso/Makefile
> > +++ b/arch/x86/entry/vdso/Makefile
> > @@ -144,6 +144,7 @@ KBUILD_CFLAGS_32 += $(call cc-option, -fno-stack-protector)
> >  KBUILD_CFLAGS_32 += $(call cc-option, -foptimize-sibling-calls)
> >  KBUILD_CFLAGS_32 += -fno-omit-frame-pointer
> >  KBUILD_CFLAGS_32 += -DDISABLE_BRANCH_PROFILING
> > +KBUILD_CFLAGS_32 += -DBUILD_VDSO
> >
> >  ifdef CONFIG_RETPOLINE
> >  ifneq ($(RETPOLINE_VDSO_CFLAGS),)
> > @@ -153,12 +154,16 @@ endif
> >
> >  $(obj)/vdso32.so.dbg: KBUILD_CFLAGS = $(KBUILD_CFLAGS_32)
> >
> > +$(obj)/vdso32/lshrdi3.o: $(srctree)/lib/lshrdi3.c FORCE
> > +       $(call if_changed_rule,cc_o_c)
>
> + Masahiro to help look at this part (I don't understand this part of kbuild).


This is a copy from scripts/Makefile.build,
which is globally used to compile %.c -> %.o


--
Best Regards
Masahiro Yamada