Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option

From: Peter Smith
Date: Wed Dec 05 2018 - 14:30:46 EST


On Wed, 5 Dec 2018 at 18:22, Nick Desaulniers <ndesaulniers@xxxxxxxxxx> wrote:
>
> On Wed, Dec 5, 2018 at 12:10 AM Ard Biesheuvel
> <ard.biesheuvel@xxxxxxxxxx> wrote:
> >
> > (+ Arnd)
> >
> > On Wed, 5 Dec 2018 at 09:06, Nathan Chancellor <natechancellor@xxxxxxxxx> wrote:
> > >
> > > On Wed, Dec 05, 2018 at 08:37:05AM +0100, Ard Biesheuvel wrote:
> > > > On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor <natechancellor@xxxxxxxxx> wrote:
> > > > >
> > > > > This flag is not supported by lld:
> > > > >
> > > > > ld.lld: error: unknown argument: --pic-veneer
> > > > >
> > > > > Signed-off-by: Nathan Chancellor <natechancellor@xxxxxxxxx>
> > > >
> > > > Hi Nate,
> > > >
> > > > Does this mean ld.lld is guaranteed to produce position independent
> > > > veneers if you build kernels that are bigger than the typical range of
> > > > a relative branch?
>
> (+ Peter) who might be able to answer this.
>

LLD will only use position independent veneers when --shared or --pie
is used, otherwise it will use veneers with absolute addresses. If the
kernel must use position independent veneers even when the rest of the
code isn't then we'll have to implement --pic-veneer.

Peter

> > > >
> > >
> > > Hi Ard,
> > >
> > > Honestly, I'm not quite sure. I saw your commit that introduced this
> > > flag and I wasn't quite sure what to make of it for lld. What
> > > configuration would I use to verify and what would I check for?
> > >
> >
> > Try building allyesconfig, and check the resulting binary for veneers
> > (which have 'veneer' in the symbol name, at least when ld.bfd emits
> > them). These veneers should not take the [virtual] address of the
> > branch target directly, but take a PC relative offset (as in the
> > example in the commit log of that patch you are referring to)
>
> Not sure clang can compile an arm32 allyesconfig (haven't tried
> personally, yet, TODO), but we could try gcc+lld.
>
> >
> > > Additionally, I have filed an LLVM bug for the lld developers to
> > > check and see if this is a flag they should support:
> > >
> > > https://bugs.llvm.org/show_bug.cgi?id=39886
> > >
> > > Thanks for the quick reply,
> > > Nathan
> > >
> > > > > ---
> > > > > arch/arm/Makefile | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> > > > > index e2a0baf36766..4fab2aa29570 100644
> > > > > --- a/arch/arm/Makefile
> > > > > +++ b/arch/arm/Makefile
> > > > > @@ -10,7 +10,7 @@
> > > > > #
> > > > > # Copyright (C) 1995-2001 by Russell King
> > > > >
> > > > > -LDFLAGS_vmlinux := --no-undefined -X --pic-veneer
> > > > > +LDFLAGS_vmlinux := --no-undefined -X $(call ld-option,--pic-veneer)
> > > > > ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
> > > > > LDFLAGS_vmlinux += --be8
> > > > > KBUILD_LDFLAGS_MODULE += --be8
> > > > > --
> > > > > 2.20.0.rc1
> > > > >
>
>
>
> --
> Thanks,
> ~Nick Desaulniers