From: Will Deacon <will.deacon@arm.com>
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Olof Johansson <olof@lixom.net>, Arnd Bergmann <arnd@arndb.de>,
Kees Cook <keescook@chromium.org>,
Catalin Marinas <catalin.marinas@arm.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] arm64: vdso: use $(LD) instead of $(CC) to link VDSO
Date: Fri, 12 Apr 2019 09:50:13 +0100 [thread overview]
Message-ID: <20190412085013.GA11629@fuggles.cambridge.arm.com> (raw)
In-Reply-To: <CAK7LNAT3=tbf+1KZ+VQRdiBKk9p90EqXL9D8Hk6Ucbv92CRyNQ@mail.gmail.com>
Hi all,
On Fri, Apr 12, 2019 at 10:21:38AM +0900, Masahiro Yamada wrote:
> On Fri, Apr 12, 2019 at 3:20 AM Nick Desaulniers
> <ndesaulniers@google.com> wrote:
> > On Thu, Apr 11, 2019 at 2:30 AM Masahiro Yamada
> > <yamada.masahiro@socionext.com> wrote:
> > >
> > > We use $(LD) to link vmlinux, modules, decompressors, etc.
> > >
> > > VDSO is the only exceptional case where $(CC) is used as the linker
> > > driver, but I do not know why we need to do so. VDSO uses a special
> > > linker script, and does not link standard libraries at all.
> > >
> > > I changed the Makefile to use $(LD) rather than $(CC). I tested this,
> > > and VDSO worked for me.
> > >
> > > Users will be able to use their favorite linker (e.g. lld instead of
> > > of bfd) by passing LD= from the command line.
> > >
> > > My plan is to rewrite all VDSO Makefiles to use $(LD), then delete
> > > cc-ldoption.
> > >
> > > Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> > > ---
> > >
> > > arch/arm64/kernel/vdso/Makefile | 13 +++----------
> > > 1 file changed, 3 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
> > > index a0af6bf6c11b..744b9dbaba03 100644
> > > --- a/arch/arm64/kernel/vdso/Makefile
> > > +++ b/arch/arm64/kernel/vdso/Makefile
> > > @@ -12,17 +12,12 @@ obj-vdso := gettimeofday.o note.o sigreturn.o
> > > targets := $(obj-vdso) vdso.so vdso.so.dbg
> > > obj-vdso := $(addprefix $(obj)/, $(obj-vdso))
> > >
> > > -ccflags-y := -shared -fno-common -fno-builtin
> >
> > Thanks for the patch; in general LGTM. Just some small questions:
> >
> > Looks like -shared and -fno-common are linker flags forwarded along,
> > but -fno-builtin is meant for the compiler, right?
>
> Definitely, -shared must be passed to the linker
> to create a shared object.
> It is listed in the linker option list:
> https://gcc.gnu.org/onlinedocs/gcc-8.3.0/gcc/Link-Options.html#Link-Options
>
>
>
> I think -fno-common is a compiler flag instead of a linker one
> as far as I understand this:
> https://gcc.gnu.org/onlinedocs/gcc-8.3.0/gcc/Code-Gen-Options.html#Code-Gen-Options
>
>
> -fno-builtin is a compiler flag:
> https://gcc.gnu.org/onlinedocs/gcc-8.3.0/gcc/C-Dialect-Options.html#C-Dialect-Options
>
>
>
> > Do we want to keep
> > that in ccflags?
>
> All source files in arch/arm64/kernel/vdso/
> are written in assembly (gettimeofday.S note.S sigreturn.S).
>
> So, -fno-common -fno-builtin for ccflags-y
> are not used.
>
> That's why I dropped them.
>
> If we want to keep them just in case,
> it is fine with me too.
I think dropping this is fine for now, but be aware that there is ongoing
work to rewrite the vdso in C, in which case we may want that back. Much
of the Makefile will probably get reworked when that happens anyway, so
no need to worry.
> > I'm not sure why it would have been added
> > intentionally; maybe Will knows? Maybe it's ok to drop.
>
> They have been here since the initial VDSO support
> by commit 9031fefde6f2a.
>
> Will, do you remember why you added these flags?
Shamelessly lifted from ppc :)
> > > -ccflags-y += -nostdlib -Wl,-soname=linux-vdso.so.1 \
> > > - $(call cc-ldoption, -Wl$(comma)--hash-style=sysv)
> > > +ldflags-y := -shared -nostdlib -soname=linux-vdso.so.1 \
> > > + $(call ld-option, --hash-style=sysv) -n -T
> >
> > Forgive my ignorance, but the man page for ld makes it looks like the
> > -T argument requires a subsequent argument `scriptfile`. Is that what
> > `$(real-prereqs)` was doing below? If so, is dropping it in this patch
> > intentional?
>
> I just re-used cmd_ld in scripts/Makefile.lib
>
>
> It will be expanded like follows:
>
> cmd_ld = $(LD) $(ld_flags) $(real-prereqs) -o $@
>
> ->
>
> $(LD) $(KBUILD_LDFLAGS) $(ldflags-y) $(LDFLAGS_$(@F)) $(real-prereqs) -o $@
>
> ->
>
> $(LD) -shared -nostdlib -soname=linux-vdso.so.1 \
> --hash-style=sysv -n -T \
> $(obj)/vdso.lds $(obj-vdso) -o $(obj)/vdso.so.dbg
Yeah, this still works, but boy is it ugly to have that dangling -T and
then grabbing the linker script from extra-y! That's also my fault though,
so I think your patch is ok.
Will
next prev parent reply other threads:[~2019-04-12 8:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-11 9:30 [PATCH] arm64: vdso: use $(LD) instead of $(CC) to link VDSO Masahiro Yamada
2019-04-11 18:18 ` Nick Desaulniers
2019-04-12 1:21 ` Masahiro Yamada
2019-04-12 8:50 ` Will Deacon [this message]
2019-04-12 17:24 ` Nick Desaulniers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190412085013.GA11629@fuggles.cambridge.arm.com \
--to=will.deacon@arm.com \
--cc=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=keescook@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ndesaulniers@google.com \
--cc=olof@lixom.net \
--cc=yamada.masahiro@socionext.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox