Date: Wed, 21 Oct 2020 10:56:06 +0200 From: Peter Zijlstra <peterz@...radead.org> To: Sami Tolvanen <samitolvanen@...gle.com> Cc: Josh Poimboeuf <jpoimboe@...hat.com>, Jann Horn <jannh@...gle.com>, the arch/x86 maintainers <x86@...nel.org>, Masahiro Yamada <masahiroy@...nel.org>, Steven Rostedt <rostedt@...dmis.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 <clang-built-linux@...glegroups.com>, Kernel Hardening <kernel-hardening@...ts.openwall.com>, linux-arch <linux-arch@...r.kernel.org>, Linux ARM <linux-arm-kernel@...ts.infradead.org>, linux-kbuild <linux-kbuild@...r.kernel.org>, kernel list <linux-kernel@...r.kernel.org>, linux-pci@...r.kernel.org Subject: Re: [PATCH v6 22/25] x86/asm: annotate indirect jumps On Tue, Oct 20, 2020 at 12:24:37PM -0700, Sami Tolvanen wrote: > > > Building allyesconfig with this series and LTO enabled, I still see > > > the following objtool warnings for vmlinux.o, grouped by source file: > > > > > > arch/x86/entry/entry_64.S: > > > __switch_to_asm()+0x0: undefined stack state > > > .entry.text+0xffd: sibling call from callable instruction with > > > modified stack frame > > > .entry.text+0x48: stack state mismatch: cfa1=7-8 cfa2=-1+0 > > > > Not sure what this one's about, there's no OBJECT_FILES_NON_STANDARD? > > Correct, because with LTO, we won't have an ELF binary to process > until we compile everything into vmlinux.o, and at that point we can > no longer skip individual object files. I think what Josh was trying to say is; this file is subject to objtool on a normal build and does not generate warnings. So why would it generate warnings when subject to objtool as result of a vmlinux run (due to LTO or otherwise). In fact, when I build a x86_64-defconfig and then run: $ objtool check -barf defconfig-build/vmlinux.o I do not see these in particular, although I do see a lot of: "sibling call from callable instruction with modified stack frame" "falls through to next function" that did not show up in the individual objtool runs during the build. The "falls through to next function" seems to be limited to things like: warning: objtool: setup_vq() falls through to next function setup_vq.cold() warning: objtool: e1000_xmit_frame() falls through to next function e1000_xmit_frame.cold() So something's weird with the .cold thing on vmlinux.o runs.
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.