On Sun, Jul 24, 2022 at 08:34:36PM +0200, Ard Biesheuvel wrote:
> Are you sure you fixed up the conflict correctly? It seems the
> __efi64_thunk end marker ends up in .rodata in your case.
Yep, I f*cked up the merge even if it was pretty easy in meld - sorry
about that.
Now it is correct but it complains differently:
vmlinux.o: warning: objtool: efi_thunk_query_variable_info_nonblocking+0x1ba: unreachable instruction
$ ./scripts/faddr2line vmlinux.o efi_thunk_query_variable_info_nonblocking+0x1ba
efi_thunk_query_variable_info_nonblocking+0x1ba/0x330:
efi_thunk_query_variable_info_nonblocking at /home/boris/kernel/linux/arch/x86/platform/efi/efi_64.c:787
(inlined by) efi_thunk_query_variable_info_nonblocking at /home/boris/kernel/linux/arch/x86/platform/efi/efi_64.c:769
and looking at the asm, it points to:
# 0 "" 2
#NO_APP
movq efi(%rip), %rax # efi.runtime, efi.runtime
movl 12(%rsp), %r8d # %sfp, prephitmp_87
leaq 16(%rsp), %r9 #,
movl %r15d, %ecx # _104,
movl %r14d, %edx # _95,
movl %ebp, %esi # attr,
movl 76(%rax), %edi # _30->mixed_mode.query_variable_info, _30->mixed_mode.query_variable_info
call __efi64_thunk #
#APP
# 787 "arch/x86/platform/efi/efi_64.c" 1
1: movl %r12d,%ds # __val <---
this here, after the __efi64_thunk call, which is that segment restoring
after the __efi_thunk call:
loadsegment(ds, __ds);
Weird, I don't see why though - that should be reachable.
--
Regards/Gruss,
Boris.
SUSE Software Solutions Germany GmbH
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman
(HRB 36809, AG Nürnberg)
