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.
