Makefile | 1 + arch/arm64/Makefile | 5 ++++- arch/loongarch/Makefile | 5 ++++- arch/riscv/Makefile | 5 ++++- scripts/link-vmlinux.sh | 5 ++--- 5 files changed, 15 insertions(+), 6 deletions(-)
When compiling with LLVM and CONFIG_LTO_CLANG is set, there exists
the following objtool warning on LoongArch:
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.
At the beginning, try to do something to make efi_boot_kernel() ends with
an unconditional jump instruction, but this modification seems not proper.
Since the efistub functions are useless for stack unwinder, they can be
ignored by objtool. After many discussions, no need to link libstub to
the vmlinux.o, only link libstub to the final vmlinux.
Do the similar things for arm64 and riscv, otherwise there may be objtool
warnings when arm64 and riscv support objtool, this is to make consistent
with the archs that use libstub.
Link: https://lore.kernel.org/lkml/pq4h7jgndnt6p45lj4kgubxjd5gidfetugcuf5rcxzxxanzetd@6rrlpjnjsmuy/
Suggested-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
---
Makefile | 1 +
arch/arm64/Makefile | 5 ++++-
arch/loongarch/Makefile | 5 ++++-
arch/riscv/Makefile | 5 ++++-
scripts/link-vmlinux.sh | 5 ++---
5 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/Makefile b/Makefile
index 10355ecf32cb..8ba2e28ef3d1 100644
--- a/Makefile
+++ b/Makefile
@@ -1201,6 +1201,7 @@ KBUILD_VMLINUX_OBJS := built-in.a $(patsubst %/, %/lib.a, $(filter %/, $(libs-y)
KBUILD_VMLINUX_LIBS := $(filter-out %/, $(libs-y))
export KBUILD_VMLINUX_LIBS
+export KBUILD_VMLINUX_LIBS_PRELINK
export KBUILD_LDS := arch/$(SRCARCH)/kernel/vmlinux.lds
ifdef CONFIG_TRIM_UNUSED_KSYMS
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 73a10f65ce8b..038f37ef2143 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -156,7 +156,10 @@ KBUILD_CPPFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
KBUILD_AFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
libs-y := arch/arm64/lib/ $(libs-y)
-libs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a
+
+ifdef CONFIG_EFI_STUB
+KBUILD_VMLINUX_LIBS_PRELINK += $(objtree)/drivers/firmware/efi/libstub/lib.a
+endif
# Default target when executing plain make
boot := arch/arm64/boot
diff --git a/arch/loongarch/Makefile b/arch/loongarch/Makefile
index ae419e32f22e..4eb904c20718 100644
--- a/arch/loongarch/Makefile
+++ b/arch/loongarch/Makefile
@@ -169,7 +169,10 @@ CHECKFLAGS += $(shell $(CC) $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) -dM -E -x c /dev
endif
libs-y += arch/loongarch/lib/
-libs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a
+
+ifdef CONFIG_EFI_STUB
+KBUILD_VMLINUX_LIBS_PRELINK += $(objtree)/drivers/firmware/efi/libstub/lib.a
+endif
drivers-y += arch/loongarch/crypto/
diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index df57654a615e..cfd82b2c1bbf 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -173,7 +173,10 @@ boot-image-$(CONFIG_XIP_KERNEL) := xipImage
KBUILD_IMAGE := $(boot)/$(boot-image-y)
libs-y += arch/riscv/lib/
-libs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a
+
+ifdef CONFIG_EFI_STUB
+KBUILD_VMLINUX_LIBS_PRELINK += $(objtree)/drivers/firmware/efi/libstub/lib.a
+endif
ifeq ($(KBUILD_EXTMOD),)
ifeq ($(CONFIG_MMU),y)
diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index 51367c2bfc21..b3cbff31d8a9 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -61,12 +61,11 @@ vmlinux_link()
shift
if is_enabled CONFIG_LTO_CLANG || is_enabled CONFIG_X86_KERNEL_IBT; then
- # Use vmlinux.o instead of performing the slow LTO link again.
objs=vmlinux.o
- libs=
+ libs="${KBUILD_VMLINUX_LIBS_PRELINK}"
else
objs=vmlinux.a
- libs="${KBUILD_VMLINUX_LIBS}"
+ libs="${KBUILD_VMLINUX_LIBS} ${KBUILD_VMLINUX_LIBS_PRELINK}"
fi
if is_enabled CONFIG_GENERIC_BUILTIN_DTB; then
--
2.42.0
On Sun, 28 Sept 2025 at 10:55, Tiezhu Yang <yangtiezhu@loongson.cn> wrote: > > When compiling with LLVM and CONFIG_LTO_CLANG is set, there exists > the following objtool warning on LoongArch: > > 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. > > At the beginning, try to do something to make efi_boot_kernel() ends with > an unconditional jump instruction, but this modification seems not proper. > > Since the efistub functions are useless for stack unwinder, they can be > ignored by objtool. After many discussions, no need to link libstub to > the vmlinux.o, only link libstub to the final vmlinux. > Please try keeping these changes confined to arch/loongarch. This problem does not exist on other architectures, and changing the way vmlinux is constructed might create other issues down the road. > Do the similar things for arm64 and riscv, otherwise there may be objtool > warnings when arm64 and riscv support objtool, this is to make consistent > with the archs that use libstub. > > Link: https://lore.kernel.org/lkml/pq4h7jgndnt6p45lj4kgubxjd5gidfetugcuf5rcxzxxanzetd@6rrlpjnjsmuy/ > Suggested-by: Josh Poimboeuf <jpoimboe@kernel.org> > Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> > --- > Makefile | 1 + > arch/arm64/Makefile | 5 ++++- > arch/loongarch/Makefile | 5 ++++- > arch/riscv/Makefile | 5 ++++- > scripts/link-vmlinux.sh | 5 ++--- > 5 files changed, 15 insertions(+), 6 deletions(-) > > diff --git a/Makefile b/Makefile > index 10355ecf32cb..8ba2e28ef3d1 100644 > --- a/Makefile > +++ b/Makefile > @@ -1201,6 +1201,7 @@ KBUILD_VMLINUX_OBJS := built-in.a $(patsubst %/, %/lib.a, $(filter %/, $(libs-y) > KBUILD_VMLINUX_LIBS := $(filter-out %/, $(libs-y)) > > export KBUILD_VMLINUX_LIBS > +export KBUILD_VMLINUX_LIBS_PRELINK > export KBUILD_LDS := arch/$(SRCARCH)/kernel/vmlinux.lds > > ifdef CONFIG_TRIM_UNUSED_KSYMS > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile > index 73a10f65ce8b..038f37ef2143 100644 > --- a/arch/arm64/Makefile > +++ b/arch/arm64/Makefile > @@ -156,7 +156,10 @@ KBUILD_CPPFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT) > KBUILD_AFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT) > > libs-y := arch/arm64/lib/ $(libs-y) > -libs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a > + > +ifdef CONFIG_EFI_STUB > +KBUILD_VMLINUX_LIBS_PRELINK += $(objtree)/drivers/firmware/efi/libstub/lib.a > +endif > > # Default target when executing plain make > boot := arch/arm64/boot > diff --git a/arch/loongarch/Makefile b/arch/loongarch/Makefile > index ae419e32f22e..4eb904c20718 100644 > --- a/arch/loongarch/Makefile > +++ b/arch/loongarch/Makefile > @@ -169,7 +169,10 @@ CHECKFLAGS += $(shell $(CC) $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) -dM -E -x c /dev > endif > > libs-y += arch/loongarch/lib/ > -libs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a > + > +ifdef CONFIG_EFI_STUB > +KBUILD_VMLINUX_LIBS_PRELINK += $(objtree)/drivers/firmware/efi/libstub/lib.a > +endif > > drivers-y += arch/loongarch/crypto/ > > diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile > index df57654a615e..cfd82b2c1bbf 100644 > --- a/arch/riscv/Makefile > +++ b/arch/riscv/Makefile > @@ -173,7 +173,10 @@ boot-image-$(CONFIG_XIP_KERNEL) := xipImage > KBUILD_IMAGE := $(boot)/$(boot-image-y) > > libs-y += arch/riscv/lib/ > -libs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a > + > +ifdef CONFIG_EFI_STUB > +KBUILD_VMLINUX_LIBS_PRELINK += $(objtree)/drivers/firmware/efi/libstub/lib.a > +endif > > ifeq ($(KBUILD_EXTMOD),) > ifeq ($(CONFIG_MMU),y) > diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh > index 51367c2bfc21..b3cbff31d8a9 100755 > --- a/scripts/link-vmlinux.sh > +++ b/scripts/link-vmlinux.sh > @@ -61,12 +61,11 @@ vmlinux_link() > shift > > if is_enabled CONFIG_LTO_CLANG || is_enabled CONFIG_X86_KERNEL_IBT; then > - # Use vmlinux.o instead of performing the slow LTO link again. > objs=vmlinux.o > - libs= > + libs="${KBUILD_VMLINUX_LIBS_PRELINK}" > else > objs=vmlinux.a > - libs="${KBUILD_VMLINUX_LIBS}" > + libs="${KBUILD_VMLINUX_LIBS} ${KBUILD_VMLINUX_LIBS_PRELINK}" > fi > > if is_enabled CONFIG_GENERIC_BUILTIN_DTB; then > -- > 2.42.0 >
Hi, Ard, On Sun, Sep 28, 2025 at 9:42 PM Ard Biesheuvel <ardb@kernel.org> wrote: > > On Sun, 28 Sept 2025 at 10:55, Tiezhu Yang <yangtiezhu@loongson.cn> wrote: > > > > When compiling with LLVM and CONFIG_LTO_CLANG is set, there exists > > the following objtool warning on LoongArch: > > > > 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. > > > > At the beginning, try to do something to make efi_boot_kernel() ends with > > an unconditional jump instruction, but this modification seems not proper. > > > > Since the efistub functions are useless for stack unwinder, they can be > > ignored by objtool. After many discussions, no need to link libstub to > > the vmlinux.o, only link libstub to the final vmlinux. > > > > Please try keeping these changes confined to arch/loongarch. This > problem does not exist on other architectures, and changing the way > vmlinux is constructed might create other issues down the road. ARM, RISC-V and LoongArch do things exactly in the same way. Now LoongArch is the first of the three to enable objtool, so we meet the problem first. But yes, I also don't want to change the way of constructing vmlinux. So I prefer the earliest way to fix this problem. https://lore.kernel.org/loongarch/CAAhV-H7fRHGFVKV8HitRgmuoDPt5ODt--iSuV0EmeeUb9d5FNw@mail.gmail.com/T/#meef7411abd14f4c28c85e686614aa9211fccdca0 Huacai > > > Do the similar things for arm64 and riscv, otherwise there may be objtool > > warnings when arm64 and riscv support objtool, this is to make consistent > > with the archs that use libstub. > > > > Link: https://lore.kernel.org/lkml/pq4h7jgndnt6p45lj4kgubxjd5gidfetugcuf5rcxzxxanzetd@6rrlpjnjsmuy/ > > Suggested-by: Josh Poimboeuf <jpoimboe@kernel.org> > > Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> > > --- > > Makefile | 1 + > > arch/arm64/Makefile | 5 ++++- > > arch/loongarch/Makefile | 5 ++++- > > arch/riscv/Makefile | 5 ++++- > > > scripts/link-vmlinux.sh | 5 ++--- > > 5 files changed, 15 insertions(+), 6 deletions(-) > > > > diff --git a/Makefile b/Makefile > > index 10355ecf32cb..8ba2e28ef3d1 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -1201,6 +1201,7 @@ KBUILD_VMLINUX_OBJS := built-in.a $(patsubst %/, %/lib.a, $(filter %/, $(libs-y) > > KBUILD_VMLINUX_LIBS := $(filter-out %/, $(libs-y)) > > > > export KBUILD_VMLINUX_LIBS > > +export KBUILD_VMLINUX_LIBS_PRELINK > > export KBUILD_LDS := arch/$(SRCARCH)/kernel/vmlinux.lds > > > > ifdef CONFIG_TRIM_UNUSED_KSYMS > > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile > > index 73a10f65ce8b..038f37ef2143 100644 > > --- a/arch/arm64/Makefile > > +++ b/arch/arm64/Makefile > > @@ -156,7 +156,10 @@ KBUILD_CPPFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT) > > KBUILD_AFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT) > > > > libs-y := arch/arm64/lib/ $(libs-y) > > -libs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a > > + > > +ifdef CONFIG_EFI_STUB > > +KBUILD_VMLINUX_LIBS_PRELINK += $(objtree)/drivers/firmware/efi/libstub/lib.a > > +endif > > > > # Default target when executing plain make > > boot := arch/arm64/boot > > diff --git a/arch/loongarch/Makefile b/arch/loongarch/Makefile > > index ae419e32f22e..4eb904c20718 100644 > > --- a/arch/loongarch/Makefile > > +++ b/arch/loongarch/Makefile > > @@ -169,7 +169,10 @@ CHECKFLAGS += $(shell $(CC) $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) -dM -E -x c /dev > > endif > > > > libs-y += arch/loongarch/lib/ > > -libs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a > > + > > +ifdef CONFIG_EFI_STUB > > +KBUILD_VMLINUX_LIBS_PRELINK += $(objtree)/drivers/firmware/efi/libstub/lib.a > > +endif > > > > drivers-y += arch/loongarch/crypto/ > > > > diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile > > index df57654a615e..cfd82b2c1bbf 100644 > > --- a/arch/riscv/Makefile > > +++ b/arch/riscv/Makefile > > @@ -173,7 +173,10 @@ boot-image-$(CONFIG_XIP_KERNEL) := xipImage > > KBUILD_IMAGE := $(boot)/$(boot-image-y) > > > > libs-y += arch/riscv/lib/ > > -libs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a > > + > > +ifdef CONFIG_EFI_STUB > > +KBUILD_VMLINUX_LIBS_PRELINK += $(objtree)/drivers/firmware/efi/libstub/lib.a > > +endif > > > > ifeq ($(KBUILD_EXTMOD),) > > ifeq ($(CONFIG_MMU),y) > > diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh > > index 51367c2bfc21..b3cbff31d8a9 100755 > > --- a/scripts/link-vmlinux.sh > > +++ b/scripts/link-vmlinux.sh > > @@ -61,12 +61,11 @@ vmlinux_link() > > shift > > > > if is_enabled CONFIG_LTO_CLANG || is_enabled CONFIG_X86_KERNEL_IBT; then > > - # Use vmlinux.o instead of performing the slow LTO link again. > > objs=vmlinux.o > > - libs= > > + libs="${KBUILD_VMLINUX_LIBS_PRELINK}" > > else > > objs=vmlinux.a > > - libs="${KBUILD_VMLINUX_LIBS}" > > + libs="${KBUILD_VMLINUX_LIBS} ${KBUILD_VMLINUX_LIBS_PRELINK}" > > fi > > > > if is_enabled CONFIG_GENERIC_BUILTIN_DTB; then > > -- > > 2.42.0 > >
On Sun, 28 Sept 2025 at 15:52, Huacai Chen <chenhuacai@kernel.org> wrote: > > Hi, Ard, > > On Sun, Sep 28, 2025 at 9:42 PM Ard Biesheuvel <ardb@kernel.org> wrote: > > > > On Sun, 28 Sept 2025 at 10:55, Tiezhu Yang <yangtiezhu@loongson.cn> wrote: > > > > > > When compiling with LLVM and CONFIG_LTO_CLANG is set, there exists > > > the following objtool warning on LoongArch: > > > > > > 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. > > > > > > At the beginning, try to do something to make efi_boot_kernel() ends with > > > an unconditional jump instruction, but this modification seems not proper. > > > > > > Since the efistub functions are useless for stack unwinder, they can be > > > ignored by objtool. After many discussions, no need to link libstub to > > > the vmlinux.o, only link libstub to the final vmlinux. > > > > > > > Please try keeping these changes confined to arch/loongarch. This > > problem does not exist on other architectures, and changing the way > > vmlinux is constructed might create other issues down the road. > ARM, RISC-V and LoongArch do things exactly in the same way. Now > LoongArch is the first of the three to enable objtool, so we meet the > problem first. > > But yes, I also don't want to change the way of constructing vmlinux. > So I prefer the earliest way to fix this problem. > https://lore.kernel.org/loongarch/CAAhV-H7fRHGFVKV8HitRgmuoDPt5ODt--iSuV0EmeeUb9d5FNw@mail.gmail.com/T/#meef7411abd14f4c28c85e686614aa9211fccdca0 > Can we just drop the __noreturn annotation from kernel_entry_t, and return EFI_SUCCESS from efi_boot_kernel()?
On Sun, Sep 28, 2025 at 10:40 PM Ard Biesheuvel <ardb@kernel.org> wrote: > > On Sun, 28 Sept 2025 at 15:52, Huacai Chen <chenhuacai@kernel.org> wrote: > > > > Hi, Ard, > > > > On Sun, Sep 28, 2025 at 9:42 PM Ard Biesheuvel <ardb@kernel.org> wrote: > > > > > > On Sun, 28 Sept 2025 at 10:55, Tiezhu Yang <yangtiezhu@loongson.cn> wrote: > > > > > > > > When compiling with LLVM and CONFIG_LTO_CLANG is set, there exists > > > > the following objtool warning on LoongArch: > > > > > > > > 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. > > > > > > > > At the beginning, try to do something to make efi_boot_kernel() ends with > > > > an unconditional jump instruction, but this modification seems not proper. > > > > > > > > Since the efistub functions are useless for stack unwinder, they can be > > > > ignored by objtool. After many discussions, no need to link libstub to > > > > the vmlinux.o, only link libstub to the final vmlinux. > > > > > > > > > > Please try keeping these changes confined to arch/loongarch. This > > > problem does not exist on other architectures, and changing the way > > > vmlinux is constructed might create other issues down the road. > > ARM, RISC-V and LoongArch do things exactly in the same way. Now > > LoongArch is the first of the three to enable objtool, so we meet the > > problem first. > > > > But yes, I also don't want to change the way of constructing vmlinux. > > So I prefer the earliest way to fix this problem. > > https://lore.kernel.org/loongarch/CAAhV-H7fRHGFVKV8HitRgmuoDPt5ODt--iSuV0EmeeUb9d5FNw@mail.gmail.com/T/#meef7411abd14f4c28c85e686614aa9211fccdca0 > > > > Can we just drop the __noreturn annotation from kernel_entry_t, and > return EFI_SUCCESS from efi_boot_kernel()? Not good, because kernel_entry_t is really "noreturn", and at present no architecture returns EFI_SUCCESS at the end of efi_boot_kernel(). Huacai
On Sun, 28 Sept 2025 at 16:39, Ard Biesheuvel <ardb@kernel.org> wrote: > > On Sun, 28 Sept 2025 at 15:52, Huacai Chen <chenhuacai@kernel.org> wrote: > > > > Hi, Ard, > > > > On Sun, Sep 28, 2025 at 9:42 PM Ard Biesheuvel <ardb@kernel.org> wrote: > > > > > > On Sun, 28 Sept 2025 at 10:55, Tiezhu Yang <yangtiezhu@loongson.cn> wrote: > > > > > > > > When compiling with LLVM and CONFIG_LTO_CLANG is set, there exists > > > > the following objtool warning on LoongArch: > > > > > > > > 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. > > > > > > > > At the beginning, try to do something to make efi_boot_kernel() ends with > > > > an unconditional jump instruction, but this modification seems not proper. > > > > > > > > Since the efistub functions are useless for stack unwinder, they can be > > > > ignored by objtool. After many discussions, no need to link libstub to > > > > the vmlinux.o, only link libstub to the final vmlinux. > > > > > > > > > > Please try keeping these changes confined to arch/loongarch. This > > > problem does not exist on other architectures, and changing the way > > > vmlinux is constructed might create other issues down the road. > > ARM, RISC-V and LoongArch do things exactly in the same way. Now > > LoongArch is the first of the three to enable objtool, so we meet the > > problem first. > > > > But yes, I also don't want to change the way of constructing vmlinux. > > So I prefer the earliest way to fix this problem. > > https://lore.kernel.org/loongarch/CAAhV-H7fRHGFVKV8HitRgmuoDPt5ODt--iSuV0EmeeUb9d5FNw@mail.gmail.com/T/#meef7411abd14f4c28c85e686614aa9211fccdca0 > > > > Can we just drop the __noreturn annotation from kernel_entry_t, and > return EFI_SUCCESS from efi_boot_kernel()? ... or add efi_boot_kernel() to ./tools/objtool/noreturns.h?
© 2016 - 2025 Red Hat, Inc.