On Wed, Oct 21, 2020 at 1:56 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > 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). Ah, right. It also doesn't generate warnings when I build defconfig with LTO, so clearly something confuses objtool here. Sami
