When compiling with LLVM and CONFIG_LTO_CLANG is set, there exists
the following objtool warning:
vmlinux.o: warning: objtool: __efistub_efi_boot_kernel()
falls through to next function __efistub_exit_boot_func()
This is because efi_boot_kernel() doesn't end with a return instruction
or an unconditional jump, then objtool has determined that the function
can fall through into the next function.
Actually, efi_boot_kernel()'s last instruction is "jirl $ra, $a3, 0", it
is a call to a noreturn function pointer real_kernel_entry() which points
to the symbol kernel_entry() in arch/loongarch/kernel/head.S.
drivers/firmware/efi/libstub/loongarch.c:
typedef void __noreturn (*kernel_entry_t)(bool efi, unsigned long cmdline,
unsigned long systab);
efi_status_t efi_boot_kernel(void *handle, efi_loaded_image_t *image,
unsigned long kernel_addr, char *cmdline_ptr)
{
kernel_entry_t real_kernel_entry;
...
real_kernel_entry = (void *)kernel_entry_address(kernel_addr, image);
real_kernel_entry(true, (unsigned long)cmdline_ptr,
(unsigned long)efi_system_table);
}
According to the description of tools/objtool/Documentation/objtool.txt,
in order to silence this warning, at the beginning just add the noreturn
real_kernel_entry() to objtool's hard-coded global_noreturns array, but
there is no effect, because it is not a valid symbol.
There exists an alternative way to silence this warning, the first thing
is to remove the attribute __noreturn for real_kernel_entry(), otherwise
the compiler can not generate instructions after that, and then just add
"while (1);" at the end of efi_boot_kernel(), so that efi_boot_kernel()
ends with an unconditional jump instruction "b".
Note that at the end of efi_boot_kernel(), using unreachable() has no
effect because it can still generate fall-through code, using BUG() is
not proper because it will generate the following ld.lld warning:
vmlinux.o:(.init__bug_table) is being placed in '.init__bug_table'
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
---
drivers/firmware/efi/libstub/loongarch.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/efi/libstub/loongarch.c b/drivers/firmware/efi/libstub/loongarch.c
index 3782d0a187d1..e309fd78fca7 100644
--- a/drivers/firmware/efi/libstub/loongarch.c
+++ b/drivers/firmware/efi/libstub/loongarch.c
@@ -10,7 +10,7 @@
#include "efistub.h"
#include "loongarch-stub.h"
-typedef void __noreturn (*kernel_entry_t)(bool efi, unsigned long cmdline,
+typedef void (*kernel_entry_t)(bool efi, unsigned long cmdline,
unsigned long systab);
efi_status_t check_platform_features(void)
@@ -81,4 +81,7 @@ efi_status_t efi_boot_kernel(void *handle, efi_loaded_image_t *image,
real_kernel_entry(true, (unsigned long)cmdline_ptr,
(unsigned long)efi_system_table);
+
+ /* We should never get here */
+ while (1);
}
--
2.42.0On Tue, Aug 26, 2025 at 2:46 PM Tiezhu Yang <yangtiezhu@loongson.cn> wrote:
>
> When compiling with LLVM and CONFIG_LTO_CLANG is set, there exists
> the following objtool warning:
>
> vmlinux.o: warning: objtool: __efistub_efi_boot_kernel()
> falls through to next function __efistub_exit_boot_func()
>
> This is because efi_boot_kernel() doesn't end with a return instruction
> or an unconditional jump, then objtool has determined that the function
> can fall through into the next function.
>
> Actually, efi_boot_kernel()'s last instruction is "jirl $ra, $a3, 0", it
> is a call to a noreturn function pointer real_kernel_entry() which points
> to the symbol kernel_entry() in arch/loongarch/kernel/head.S.
>
> drivers/firmware/efi/libstub/loongarch.c:
>
> typedef void __noreturn (*kernel_entry_t)(bool efi, unsigned long cmdline,
> unsigned long systab);
>
> efi_status_t efi_boot_kernel(void *handle, efi_loaded_image_t *image,
> unsigned long kernel_addr, char *cmdline_ptr)
> {
> kernel_entry_t real_kernel_entry;
> ...
> real_kernel_entry = (void *)kernel_entry_address(kernel_addr, image);
>
> real_kernel_entry(true, (unsigned long)cmdline_ptr,
> (unsigned long)efi_system_table);
> }
>
> According to the description of tools/objtool/Documentation/objtool.txt,
> in order to silence this warning, at the beginning just add the noreturn
> real_kernel_entry() to objtool's hard-coded global_noreturns array, but
> there is no effect, because it is not a valid symbol.
>
> There exists an alternative way to silence this warning, the first thing
> is to remove the attribute __noreturn for real_kernel_entry(), otherwise
> the compiler can not generate instructions after that, and then just add
> "while (1);" at the end of efi_boot_kernel(), so that efi_boot_kernel()
> ends with an unconditional jump instruction "b".
>
> Note that at the end of efi_boot_kernel(), using unreachable() has no
> effect because it can still generate fall-through code, using BUG() is
> not proper because it will generate the following ld.lld warning:
>
> vmlinux.o:(.init__bug_table) is being placed in '.init__bug_table'
>
> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
> ---
> drivers/firmware/efi/libstub/loongarch.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/efi/libstub/loongarch.c b/drivers/firmware/efi/libstub/loongarch.c
> index 3782d0a187d1..e309fd78fca7 100644
> --- a/drivers/firmware/efi/libstub/loongarch.c
> +++ b/drivers/firmware/efi/libstub/loongarch.c
> @@ -10,7 +10,7 @@
> #include "efistub.h"
> #include "loongarch-stub.h"
>
> -typedef void __noreturn (*kernel_entry_t)(bool efi, unsigned long cmdline,
> +typedef void (*kernel_entry_t)(bool efi, unsigned long cmdline,
> unsigned long systab);
From my point of view this is incorrect, this function is indeed a
noreturn function, and this modification makes LoongArch different to
other architectures.
Maybe it is better to let objtool ignore the whole
drivers/firmware/efi/libstub directory. Because efistub is discarded
at runtime so it is useless for stack unwinder.
Huacai
>
> efi_status_t check_platform_features(void)
> @@ -81,4 +81,7 @@ efi_status_t efi_boot_kernel(void *handle, efi_loaded_image_t *image,
>
> real_kernel_entry(true, (unsigned long)cmdline_ptr,
> (unsigned long)efi_system_table);
> +
> + /* We should never get here */
> + while (1);
> }
> --
> 2.42.0
>
On 2025/8/26 下午4:32, Huacai Chen wrote: > On Tue, Aug 26, 2025 at 2:46 PM Tiezhu Yang <yangtiezhu@loongson.cn> wrote: >> >> When compiling with LLVM and CONFIG_LTO_CLANG is set, there exists >> the following objtool warning: >> >> vmlinux.o: warning: objtool: __efistub_efi_boot_kernel() >> falls through to next function __efistub_exit_boot_func() ... >> -typedef void __noreturn (*kernel_entry_t)(bool efi, unsigned long cmdline, >> +typedef void (*kernel_entry_t)(bool efi, unsigned long cmdline, >> unsigned long systab); > From my point of view this is incorrect, this function is indeed a > noreturn function, and this modification makes LoongArch different to > other architectures. > > Maybe it is better to let objtool ignore the whole > drivers/firmware/efi/libstub directory. Because efistub is discarded > at runtime so it is useless for stack unwinder. I tested the following change but there is no effect, the objtool warning still exists, this is because OBJECT_FILES_NON_STANDARD does not work for link time validation of vmlinux.o according to tools/objtool/Documentation/objtool.txt. diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile index 8efbcf699e4f..f1fff48eea76 100644 --- a/drivers/firmware/efi/Makefile +++ b/drivers/firmware/efi/Makefile @@ -10,6 +10,8 @@ # KASAN_SANITIZE_runtime-wrappers.o := n +OBJECT_FILES_NON_STANDARD := y + obj-$(CONFIG_ACPI_BGRT) += efi-bgrt.o obj-$(CONFIG_EFI) += efi.o vars.o reboot.o memattr.o tpm.o obj-$(CONFIG_EFI) += memmap.o Thanks, Tiezhu
On Tue, Aug 26, 2025 at 8:33 PM Tiezhu Yang <yangtiezhu@loongson.cn> wrote: > > On 2025/8/26 下午4:32, Huacai Chen wrote: > > On Tue, Aug 26, 2025 at 2:46 PM Tiezhu Yang <yangtiezhu@loongson.cn> wrote: > >> > >> When compiling with LLVM and CONFIG_LTO_CLANG is set, there exists > >> the following objtool warning: > >> > >> vmlinux.o: warning: objtool: __efistub_efi_boot_kernel() > >> falls through to next function __efistub_exit_boot_func() > > ... > > >> -typedef void __noreturn (*kernel_entry_t)(bool efi, unsigned long cmdline, > >> +typedef void (*kernel_entry_t)(bool efi, unsigned long cmdline, > >> unsigned long systab); > > From my point of view this is incorrect, this function is indeed a > > noreturn function, and this modification makes LoongArch different to > > other architectures. > > > > Maybe it is better to let objtool ignore the whole > > drivers/firmware/efi/libstub directory. Because efistub is discarded > > at runtime so it is useless for stack unwinder. > > I tested the following change but there is no effect, the objtool > warning still exists, this is because OBJECT_FILES_NON_STANDARD > does not work for link time validation of vmlinux.o according to > tools/objtool/Documentation/objtool.txt. Then I think objtool needs to be improved to handle this case, this problem is not arch specific. Huacai > > diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile > index 8efbcf699e4f..f1fff48eea76 100644 > --- a/drivers/firmware/efi/Makefile > +++ b/drivers/firmware/efi/Makefile > @@ -10,6 +10,8 @@ > # > KASAN_SANITIZE_runtime-wrappers.o := n > > +OBJECT_FILES_NON_STANDARD := y > + > obj-$(CONFIG_ACPI_BGRT) += efi-bgrt.o > obj-$(CONFIG_EFI) += efi.o vars.o reboot.o > memattr.o tpm.o > obj-$(CONFIG_EFI) += memmap.o > > Thanks, > Tiezhu > >
On Tue, Aug 26, 2025 at 09:03:34PM +0800, Huacai Chen wrote: > On Tue, Aug 26, 2025 at 8:33 PM Tiezhu Yang <yangtiezhu@loongson.cn> wrote: > > > > On 2025/8/26 下午4:32, Huacai Chen wrote: > > > On Tue, Aug 26, 2025 at 2:46 PM Tiezhu Yang <yangtiezhu@loongson.cn> wrote: > > >> > > >> When compiling with LLVM and CONFIG_LTO_CLANG is set, there exists > > >> the following objtool warning: > > >> > > >> vmlinux.o: warning: objtool: __efistub_efi_boot_kernel() > > >> falls through to next function __efistub_exit_boot_func() > > > > ... > > > > >> -typedef void __noreturn (*kernel_entry_t)(bool efi, unsigned long cmdline, > > >> +typedef void (*kernel_entry_t)(bool efi, unsigned long cmdline, > > >> unsigned long systab); > > > From my point of view this is incorrect, this function is indeed a > > > noreturn function, and this modification makes LoongArch different to > > > other architectures. > > > > > > Maybe it is better to let objtool ignore the whole > > > drivers/firmware/efi/libstub directory. Because efistub is discarded > > > at runtime so it is useless for stack unwinder. > > > > I tested the following change but there is no effect, the objtool > > warning still exists, this is because OBJECT_FILES_NON_STANDARD > > does not work for link time validation of vmlinux.o according to > > tools/objtool/Documentation/objtool.txt. > Then I think objtool needs to be improved to handle this case, this > problem is not arch specific. Yeah, objtool should really be ignoring this code altogether. On x86, that's not a problem because the EFI stub code isn't linked into vmlinux.o. It gets linked in separately: $ git grep vmlinux-libs arch/x86/boot/compressed/Makefile:vmlinux-libs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a arch/x86/boot/compressed/Makefile:vmlinux-libs-$(CONFIG_X86_64) += $(objtree)/arch/x86/boot/startup/lib.a arch/x86/boot/compressed/Makefile:$(obj)/vmlinux: $(vmlinux-objs-y) $(vmlinux-libs-y) FORCE IMO, the proper fix is to change the loongarch build to do the same. vmlinux.o is intended to be proper kernel code. -- Josh
On 2025/8/27 上午7:39, Josh Poimboeuf wrote: > On Tue, Aug 26, 2025 at 09:03:34PM +0800, Huacai Chen wrote: ... >> Then I think objtool needs to be improved to handle this case, this >> problem is not arch specific. > > Yeah, objtool should really be ignoring this code altogether. On x86, > that's not a problem because the EFI stub code isn't linked into > vmlinux.o. It gets linked in separately: > > $ git grep vmlinux-libs > arch/x86/boot/compressed/Makefile:vmlinux-libs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a > arch/x86/boot/compressed/Makefile:vmlinux-libs-$(CONFIG_X86_64) += $(objtree)/arch/x86/boot/startup/lib.a > arch/x86/boot/compressed/Makefile:$(obj)/vmlinux: $(vmlinux-objs-y) $(vmlinux-libs-y) FORCE > > IMO, the proper fix is to change the loongarch build to do the same. > vmlinux.o is intended to be proper kernel code. Thank you very much, that is to say, these EFISTUB functions can be ignored by objtool, I will do it. Thanks, Tiezhu
© 2016 - 2025 Red Hat, Inc.