[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200625193217.GA59566@google.com>
Date: Thu, 25 Jun 2020 12:32:17 -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 08:33:51PM +0200, Peter Zijlstra wrote:
> On Thu, Jun 25, 2020 at 09:22:26AM -0700, Sami Tolvanen wrote:
> > On Thu, Jun 25, 2020 at 09:47:16AM +0200, Peter Zijlstra wrote:
>
> > > 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?
>
> Think we can remove it; it was just convenient when running manually.
Great, I'll change this in v2.
> > > > > > +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.
>
> Well, that I understand, my question was why we need one in
> scripts/link-vmlinux.sh and an additional one. I think we're just
> talking past one another and agree we only need one.
We need just one for vmlinux.o, but this rule adds an objtool invocation
for kernel modules, which we also couldn't check earlier. We link all
the bitcode for modules into <module>.lto.o and run modpost and objtool
on that before building the final .ko.
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.
