On Fri, Nov 13, 2020 at 12:24:32PM -0800, Sami Tolvanen wrote: > On Fri, Nov 13, 2020 at 11:54 AM Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > > > > On Tue, Nov 10, 2020 at 10:59:55AM -0800, Sami Tolvanen wrote: > > > On Tue, Nov 10, 2020 at 9:46 AM Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > > > > > > > > On Mon, Nov 09, 2020 at 08:29:24PM -0600, Josh Poimboeuf wrote: > > > > > On Mon, Nov 09, 2020 at 03:11:41PM -0800, Sami Tolvanen wrote: > > > > > > CONFIG_XEN > > > > > > > > > > > > __switch_to_asm()+0x0: undefined stack state > > > > > > xen_hypercall_set_trap_table()+0x0: <=== (sym) > > > > > > > > With your branch + GCC 9 I can recreate all the warnings except this > > > > one. > > > > > > In a gcc build this warning is replaced with a different one: > > > > > > vmlinux.o: warning: objtool: __startup_secondary_64()+0x7: return with > > > modified stack frame > > > > > > This just seems to depend on which function is placed right after the > > > code in xen-head.S. With gcc, the disassembly looks like this: > > > > > > 0000000000000000 <asm_cpu_bringup_and_idle>: > > > 0: e8 00 00 00 00 callq 5 <asm_cpu_bringup_and_idle+0x5> > > > 1: R_X86_64_PLT32 cpu_bringup_and_idle-0x4 > > > 5: e9 f6 0f 00 00 jmpq 1000 > > > <xen_hypercall_set_trap_table> > > > ... > > > 0000000000001000 <xen_hypercall_set_trap_table>: > > > ... > > > ... > > > 0000000000002000 <__startup_secondary_64>: > > > > > > With Clang+LTO, we end up with __switch_to_asm here instead of > > > __startup_secondary_64. > > > > I still don't see this warning for some reason. > > Do you have CONFIG_XEN enabled? I can reproduce this on ToT master as follows: > > $ git rev-parse HEAD > 585e5b17b92dead8a3aca4e3c9876fbca5f7e0ba > $ make defconfig && \ > ./scripts/config -e HYPERVISOR_GUEST -e PARAVIRT -e XEN && \ > make olddefconfig && \ > make -j110 > ... > $ ./tools/objtool/objtool check -arfld vmlinux.o 2>&1 | grep secondary > vmlinux.o: warning: objtool: __startup_secondary_64()+0x2: return with > modified stack frame Ok, I see it now on Linus' tree. I just didn't see it on your clang-lto branch. -- Josh
