[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 25 Jun 2020 09:22:26 -0700
From: Sami Tolvanen <samitolvanen@...gle.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Masahiro Yamada <masahiroy@...nel.org>, Will Deacon <will@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Paul E. McKenney" <paulmck@...nel.org>,
Kees Cook <keescook@...omium.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
clang-built-linux@...glegroups.com,
kernel-hardening@...ts.openwall.com, linux-arch@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kbuild@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
x86@...nel.org
Subject: Re: [PATCH 05/22] kbuild: lto: postpone objtool
On Thu, Jun 25, 2020 at 09:47:16AM +0200, Peter Zijlstra wrote:
> On Wed, Jun 24, 2020 at 02:49:25PM -0700, Sami Tolvanen wrote:
> > On Wed, Jun 24, 2020 at 11:19:08PM +0200, Peter Zijlstra wrote:
> > > On Wed, Jun 24, 2020 at 01:31:43PM -0700, Sami Tolvanen wrote:
> > > > diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> > > > index 30827f82ad62..12b115152532 100644
> > > > --- a/include/linux/compiler.h
> > > > +++ b/include/linux/compiler.h
> > > > @@ -120,7 +120,7 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
> > > > /* Annotate a C jump table to allow objtool to follow the code flow */
> > > > #define __annotate_jump_table __section(.rodata..c_jump_table)
> > > >
> > > > -#ifdef CONFIG_DEBUG_ENTRY
> > > > +#if defined(CONFIG_DEBUG_ENTRY) || defined(CONFIG_LTO_CLANG)
> > > > /* Begin/end of an instrumentation safe region */
> > > > #define instrumentation_begin() ({ \
> > > > asm volatile("%c0:\n\t" \
> > >
> > > Why would you be doing noinstr validation for lto builds? That doesn't
> > > make sense.
> >
> > This is just to avoid a ton of noinstr warnings when we run objtool on
> > vmlinux.o, but I'm also fine with skipping noinstr validation with LTO.
>
> Right, then we need to make --no-vmlinux work properly when
> !DEBUG_ENTRY, which I think might be buggered due to us overriding the
> argument when the objname ends with "vmlinux.o".
Right. Can we just remove that and pass --vmlinux to objtool in
link-vmlinux.sh, or is the override necessary somewhere else?
> > > > +ifdef CONFIG_STACK_VALIDATION
> > > > +ifneq ($(SKIP_STACK_VALIDATION),1)
> > > > +cmd_ld_ko_o += \
> > > > + $(objtree)/tools/objtool/objtool \
> > > > + $(if $(CONFIG_UNWINDER_ORC),orc generate,check) \
> > > > + --module \
> > > > + $(if $(CONFIG_FRAME_POINTER),,--no-fp) \
> > > > + $(if $(CONFIG_GCOV_KERNEL),--no-unreachable,) \
> > > > + $(if $(CONFIG_RETPOLINE),--retpoline,) \
> > > > + $(if $(CONFIG_X86_SMAP),--uaccess,) \
> > > > + $(@:.ko=$(prelink-ext).o);
> > > > +
> > > > +endif # SKIP_STACK_VALIDATION
> > > > +endif # CONFIG_STACK_VALIDATION
> > >
> > > What about the objtool invocation from link-vmlinux.sh ?
> >
> > What about it? The existing objtool_link invocation in link-vmlinux.sh
> > works fine for our purposes as well.
>
> Well, I was wondering why you're adding yet another objtool invocation
> while we already have one.
Because we can't run objtool until we have compiled bitcode to native
code, so for modules, we're need another invocation after everything has
been compiled.
Sami
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
