[PATCH v1 0/3] Fix objtool warnings if LTO is enabled for LoongArch (Part 2)

[PATCH v1 0/3] Fix objtool warnings if LTO is enabled for LoongArch (Part 2)

[Tiezhu Yang]

The previous patches [1] [2] are to fix most of the warnings (total 3030):

  sibling call from callable instruction with modified stack frame

This series is a follow up to fix 2 kinds of warnings (total 24), it only
touches the objtool and LoongArch related code:

  falls through to next function
  unreachable instruction

With this series, there is only 1 kind of warning (total 3), it does not
only touch the objtool and LoongArch related code:

  missing __noreturn in .c/.h or NORETURN() in noreturns.h

In order to silence the above warnings, it needs to change the related
code to give the functions __noreturn attribute, and have a NORETURN()
annotation in tools/objtool/noreturns.h. IMO, it will touch all of the
archs and the generic code, so this needs much more work to avoid the
side effect or regression, once it is done I will send out the patch.

Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a47bc954cf0e [1]
Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5dfea6644d20 [2]

Tiezhu Yang (3):
  objtool/LoongArch: Fix fall through warning about efi_boot_kernel()
  objtool/LoongArch: Fix unreachable instruction warnings about EFISTUB
  LoongArch: Fix unreachable instruction warnings about entry functions

 arch/loongarch/kernel/Makefile | 2 --
 arch/loongarch/kernel/head.S   | 6 ++----
 tools/objtool/check.c          | 8 ++++++++
 3 files changed, 10 insertions(+), 6 deletions(-)

-- 
2.42.0

[PATCH v1 1/3] objtool/LoongArch: Fix fall through warning about efi_boot_kernel()

[Tiezhu Yang]

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.

At the beginning, try to do something to make efi_boot_kernel() ends with
an unconditional jump instruction, but it is not a proper way.

After more analysis, one simple way is to ignore these EFISTUB functions
in validate_branch() of objtool since they are useless for stack unwinder.

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
---
 tools/objtool/check.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index d14f20ef1db1..2dcebf75d95e 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -3567,6 +3567,10 @@ static int validate_branch(struct objtool_file *file, struct symbol *func,
 			    !strncmp(func->name, "__pfx_", 6))
 				return 0;
 
+			/* Ignore EFISTUB functions which are useless for stack unwinder */
+			if (!strncmp(func->name, "__efistub_", 10))
+				return 0;
+
 			if (file->ignore_unreachables)
 				return 0;
 
-- 
2.42.0

[PATCH v1 2/3] objtool/LoongArch: Fix unreachable instruction warnings about EFISTUB

[Tiezhu Yang]

When compiling with LLVM and CONFIG_LTO_CLANG is set, there exist the
following objtool warnings:

  vmlinux.o: warning: objtool: .head.text+0x0: unreachable instruction
  vmlinux.o: warning: objtool: .head.text+0x18: unreachable instruction
  vmlinux.o: warning: objtool: .head.text+0x38: unreachable instruction
  vmlinux.o: warning: objtool: .head.text+0x3c: unreachable instruction
  vmlinux.o: warning: objtool: .head.text+0x40: unreachable instruction
  vmlinux.o: warning: objtool: .head.text+0x44: unreachable instruction
  vmlinux.o: warning: objtool: .head.text+0x54: unreachable instruction
  vmlinux.o: warning: objtool: .head.text+0x58: unreachable instruction
  vmlinux.o: warning: objtool: .head.text+0x6c: unreachable instruction
  vmlinux.o: warning: objtool: .head.text+0x84: unreachable instruction
  vmlinux.o: warning: objtool: .head.text+0x94: unreachable instruction
  vmlinux.o: warning: objtool: .head.text+0x9c: unreachable instruction
  vmlinux.o: warning: objtool: .head.text+0xc4: unreachable instruction
  vmlinux.o: warning: objtool: .head.text+0xf8: unreachable instruction
  vmlinux.o: warning: objtool: .head.text+0xfc: unreachable instruction
  vmlinux.o: warning: objtool: .head.text+0x104: unreachable instruction
  vmlinux.o: warning: objtool: .head.text+0x10c: unreachable instruction
  vmlinux.o: warning: objtool: .head.text+0x11c: unreachable instruction
  vmlinux.o: warning: objtool: .head.text+0x120: unreachable instruction
  vmlinux.o: warning: objtool: .head.text+0x124: unreachable instruction
  vmlinux.o: warning: objtool: .head.text+0x144: unreachable instruction

The instructions in the .head.text section are related with EFISTUB,
they are image header and can be ignored by objtool, so just check the
section name in ignore_unreachable_insn() to ignore it.

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
---
 tools/objtool/check.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 2dcebf75d95e..b7397b0f9f79 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -4039,6 +4039,10 @@ static bool ignore_unreachable_insn(struct objtool_file *file, struct instructio
 	    !strcmp(insn->sec->name, ".altinstr_aux"))
 		return true;
 
+	/* Ignore EFISTUB instructions usually in the .head.text section. */
+	if (!strcmp(insn->sec->name, ".head.text"))
+		return true;
+
 	/*
 	 * Whole archive runs might encounter dead code from weak symbols.
 	 * This is where the linker will have dropped the weak symbol in
-- 
2.42.0

[PATCH v1 3/3] LoongArch: Fix unreachable instruction warnings about entry functions

[Tiezhu Yang]

When compiling with LLVM and CONFIG_LTO_CLANG is set, there exist the
following objtool warnings:

  vmlinux.o: warning: objtool: kernel_entry+0x0: unreachable instruction
  vmlinux.o: warning: objtool: smpboot_entry+0x0: unreachable instruction

kernel_entry() and smpboot_entry() are in arch/loongarch/kernel/head.S,
there is "OBJECT_FILES_NON_STANDARD_head.o := y" to skip objtool checking
for head.o, but the STACK_FRAME_NON_STANDARD macro does not work for link
time validation of vmlinux.o according to objtool documentation, just give
a proper unwind hint to silence the warnings.

By the way, ASM_BUG() can be removed due to unnecessary, otherwise there
are following warnings:

  kernel_entry+0xf4: start_kernel() missing __noreturn
  in .c/.h or NORETURN() in noreturns.h

  smpboot_entry+0x68: start_secondary() missing __noreturn
  in .c/.h or NORETURN() in noreturns.h

This is because the previous instructions of kernel_entry+0xf4 and
smpboot_entry+0x68 are the 'bl' instructions, start_kernel() and
start_secondary() are the respective call destination symbols which
are noreturn functions, then the 'bl' instructions are already marked
as dead end in annotate_call_site().

For now, it is time to remove "OBJECT_FILES_NON_STANDARD_head.o := y"
in arch/loongarch/kernel/Makefile.

Link: https://lore.kernel.org/lkml/20250814083651.GR4067720@noisy.programming.kicks-ass.net/
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
---
 arch/loongarch/kernel/Makefile | 2 --
 arch/loongarch/kernel/head.S   | 6 ++----
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/loongarch/kernel/Makefile b/arch/loongarch/kernel/Makefile
index 6f5a4574a911..4302c5b0a201 100644
--- a/arch/loongarch/kernel/Makefile
+++ b/arch/loongarch/kernel/Makefile
@@ -3,8 +3,6 @@
 # Makefile for the Linux/LoongArch kernel.
 #
 
-OBJECT_FILES_NON_STANDARD_head.o := y
-
 always-$(KBUILD_BUILTIN)	:= vmlinux.lds
 
 obj-y		+= head.o cpu-probe.o cacheinfo.o env.o setup.o entry.o genex.o \
diff --git a/arch/loongarch/kernel/head.S b/arch/loongarch/kernel/head.S
index e3865e92a917..a11880f3a7e1 100644
--- a/arch/loongarch/kernel/head.S
+++ b/arch/loongarch/kernel/head.S
@@ -42,6 +42,7 @@ SYM_DATA(kernel_fsize, .long _kernel_fsize);
 	.align 12
 
 SYM_CODE_START(kernel_entry)			# kernel entry point
+	UNWIND_HINT_UNDEFINED
 
 	/* Config direct window and set PG */
 	SETUP_DMWINS	t0
@@ -109,8 +110,6 @@ SYM_CODE_START(kernel_entry)			# kernel entry point
 #endif
 
 	bl		start_kernel
-	ASM_BUG()
-
 SYM_CODE_END(kernel_entry)
 
 #ifdef CONFIG_SMP
@@ -120,6 +119,7 @@ SYM_CODE_END(kernel_entry)
  * function after setting up the stack and tp registers.
  */
 SYM_CODE_START(smpboot_entry)
+	UNWIND_HINT_UNDEFINED
 
 	SETUP_DMWINS	t0
 	JUMP_VIRT_ADDR	t0, t1
@@ -142,8 +142,6 @@ SYM_CODE_START(smpboot_entry)
 	ld.d		tp, t0, CPU_BOOT_TINFO
 
 	bl		start_secondary
-	ASM_BUG()
-
 SYM_CODE_END(smpboot_entry)
 
 #endif /* CONFIG_SMP */
-- 
2.42.0

Re: [PATCH v1 1/3] objtool/LoongArch: Fix fall through warning about efi_boot_kernel()

[Peter Zijlstra]

On Mon, Sep 01, 2025 at 03:21:54PM +0800, Tiezhu Yang 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.
> 
> At the beginning, try to do something to make efi_boot_kernel() ends with
> an unconditional jump instruction, but it is not a proper way.
> 
> After more analysis, one simple way is to ignore these EFISTUB functions
> in validate_branch() of objtool since they are useless for stack unwinder.
> 

This is drivers/firmware/efi/libstub/loongarch.c:efi_boot_kernel(),
right?

Why not simply do something like:

diff --git a/drivers/firmware/efi/libstub/loongarch.c b/drivers/firmware/efi/libstub/loongarch.c
index 3782d0a187d1..082611a5f1f0 100644
--- a/drivers/firmware/efi/libstub/loongarch.c
+++ b/drivers/firmware/efi/libstub/loongarch.c
@@ -81,4 +81,5 @@ 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);
+	BUG();
 }

Re: [PATCH v1 2/3] objtool/LoongArch: Fix unreachable instruction warnings about EFISTUB

[Peter Zijlstra]

On Mon, Sep 01, 2025 at 03:21:55PM +0800, Tiezhu Yang wrote:
> When compiling with LLVM and CONFIG_LTO_CLANG is set, there exist the
> following objtool warnings:
> 
>   vmlinux.o: warning: objtool: .head.text+0x0: unreachable instruction
>   vmlinux.o: warning: objtool: .head.text+0x18: unreachable instruction
>   vmlinux.o: warning: objtool: .head.text+0x38: unreachable instruction
>   vmlinux.o: warning: objtool: .head.text+0x3c: unreachable instruction
>   vmlinux.o: warning: objtool: .head.text+0x40: unreachable instruction
>   vmlinux.o: warning: objtool: .head.text+0x44: unreachable instruction
>   vmlinux.o: warning: objtool: .head.text+0x54: unreachable instruction
>   vmlinux.o: warning: objtool: .head.text+0x58: unreachable instruction
>   vmlinux.o: warning: objtool: .head.text+0x6c: unreachable instruction
>   vmlinux.o: warning: objtool: .head.text+0x84: unreachable instruction
>   vmlinux.o: warning: objtool: .head.text+0x94: unreachable instruction
>   vmlinux.o: warning: objtool: .head.text+0x9c: unreachable instruction
>   vmlinux.o: warning: objtool: .head.text+0xc4: unreachable instruction
>   vmlinux.o: warning: objtool: .head.text+0xf8: unreachable instruction
>   vmlinux.o: warning: objtool: .head.text+0xfc: unreachable instruction
>   vmlinux.o: warning: objtool: .head.text+0x104: unreachable instruction
>   vmlinux.o: warning: objtool: .head.text+0x10c: unreachable instruction
>   vmlinux.o: warning: objtool: .head.text+0x11c: unreachable instruction
>   vmlinux.o: warning: objtool: .head.text+0x120: unreachable instruction
>   vmlinux.o: warning: objtool: .head.text+0x124: unreachable instruction
>   vmlinux.o: warning: objtool: .head.text+0x144: unreachable instruction
> 
> The instructions in the .head.text section are related with EFISTUB,
> they are image header and can be ignored by objtool, so just check the
> section name in ignore_unreachable_insn() to ignore it.

I am confused; why do the efi/libstub functions generate this error?

Is this zboot-header.S perhaps? Why can't we properly annotate that
file?

Re: [PATCH v1 3/3] LoongArch: Fix unreachable instruction warnings about entry functions

[Peter Zijlstra]

On Mon, Sep 01, 2025 at 03:21:56PM +0800, Tiezhu Yang wrote:
> When compiling with LLVM and CONFIG_LTO_CLANG is set, there exist the
> following objtool warnings:
> 
>   vmlinux.o: warning: objtool: kernel_entry+0x0: unreachable instruction
>   vmlinux.o: warning: objtool: smpboot_entry+0x0: unreachable instruction
> 
> kernel_entry() and smpboot_entry() are in arch/loongarch/kernel/head.S,
> there is "OBJECT_FILES_NON_STANDARD_head.o := y" to skip objtool checking
> for head.o, but the STACK_FRAME_NON_STANDARD macro does not work for link
> time validation of vmlinux.o according to objtool documentation, just give
> a proper unwind hint to silence the warnings.
> 
> By the way, ASM_BUG() can be removed due to unnecessary, otherwise there
> are following warnings:
> 
>   kernel_entry+0xf4: start_kernel() missing __noreturn
>   in .c/.h or NORETURN() in noreturns.h
> 
>   smpboot_entry+0x68: start_secondary() missing __noreturn
>   in .c/.h or NORETURN() in noreturns.h
> 
> This is because the previous instructions of kernel_entry+0xf4 and
> smpboot_entry+0x68 are the 'bl' instructions, start_kernel() and
> start_secondary() are the respective call destination symbols which
> are noreturn functions, then the 'bl' instructions are already marked
> as dead end in annotate_call_site().
> 
> For now, it is time to remove "OBJECT_FILES_NON_STANDARD_head.o := y"
> in arch/loongarch/kernel/Makefile.
> 
> Link: https://lore.kernel.org/lkml/20250814083651.GR4067720@noisy.programming.kicks-ass.net/
> Suggested-by: Peter Zijlstra <peterz@infradead.org>
> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

Right, this looks good.

Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>

> ---
>  arch/loongarch/kernel/Makefile | 2 --
>  arch/loongarch/kernel/head.S   | 6 ++----
>  2 files changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/loongarch/kernel/Makefile b/arch/loongarch/kernel/Makefile
> index 6f5a4574a911..4302c5b0a201 100644
> --- a/arch/loongarch/kernel/Makefile
> +++ b/arch/loongarch/kernel/Makefile
> @@ -3,8 +3,6 @@
>  # Makefile for the Linux/LoongArch kernel.
>  #
>  
> -OBJECT_FILES_NON_STANDARD_head.o := y
> -
>  always-$(KBUILD_BUILTIN)	:= vmlinux.lds
>  
>  obj-y		+= head.o cpu-probe.o cacheinfo.o env.o setup.o entry.o genex.o \
> diff --git a/arch/loongarch/kernel/head.S b/arch/loongarch/kernel/head.S
> index e3865e92a917..a11880f3a7e1 100644
> --- a/arch/loongarch/kernel/head.S
> +++ b/arch/loongarch/kernel/head.S
> @@ -42,6 +42,7 @@ SYM_DATA(kernel_fsize, .long _kernel_fsize);
>  	.align 12
>  
>  SYM_CODE_START(kernel_entry)			# kernel entry point
> +	UNWIND_HINT_UNDEFINED
>  
>  	/* Config direct window and set PG */
>  	SETUP_DMWINS	t0
> @@ -109,8 +110,6 @@ SYM_CODE_START(kernel_entry)			# kernel entry point
>  #endif
>  
>  	bl		start_kernel
> -	ASM_BUG()
> -
>  SYM_CODE_END(kernel_entry)
>  
>  #ifdef CONFIG_SMP
> @@ -120,6 +119,7 @@ SYM_CODE_END(kernel_entry)
>   * function after setting up the stack and tp registers.
>   */
>  SYM_CODE_START(smpboot_entry)
> +	UNWIND_HINT_UNDEFINED
>  
>  	SETUP_DMWINS	t0
>  	JUMP_VIRT_ADDR	t0, t1
> @@ -142,8 +142,6 @@ SYM_CODE_START(smpboot_entry)
>  	ld.d		tp, t0, CPU_BOOT_TINFO
>  
>  	bl		start_secondary
> -	ASM_BUG()
> -
>  SYM_CODE_END(smpboot_entry)
>  
>  #endif /* CONFIG_SMP */
> -- 
> 2.42.0
> 

Re: [PATCH v1 1/3] objtool/LoongArch: Fix fall through warning about efi_boot_kernel()

[Tiezhu Yang]

On 2025/9/1 下午4:16, Peter Zijlstra wrote:
> On Mon, Sep 01, 2025 at 03:21:54PM +0800, Tiezhu Yang 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.
>>
>> At the beginning, try to do something to make efi_boot_kernel() ends with
>> an unconditional jump instruction, but it is not a proper way.
>>
>> After more analysis, one simple way is to ignore these EFISTUB functions
>> in validate_branch() of objtool since they are useless for stack unwinder.
>>
> 
> This is drivers/firmware/efi/libstub/loongarch.c:efi_boot_kernel(),
> right?
> 
> Why not simply do something like:
> 
> diff --git a/drivers/firmware/efi/libstub/loongarch.c b/drivers/firmware/efi/libstub/loongarch.c
> index 3782d0a187d1..082611a5f1f0 100644
> --- a/drivers/firmware/efi/libstub/loongarch.c
> +++ b/drivers/firmware/efi/libstub/loongarch.c
> @@ -81,4 +81,5 @@ 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);
> +	BUG();
>   }

At the beginning, I did the above change, but no effect.

The first thing is to remove the attribute __noreturn for
real_kernel_entry(), otherwise the compiler can not generate
instructions after that.

But there is an argument in the previous RFC [1]:

"From my point of view this is incorrect, this function is indeed a
noreturn function, and this modification makes LoongArch different to
other architectures."

Josh suggested to do something so that the EFI stub code isn't linked 
into vmlinux.o [2], it needs to modify the link process and seems too
complicated and expensive for this warning to some extent.

So I did this change for objtool.

[1] 
https://lore.kernel.org/loongarch/CAAhV-H5wW_04NHQ7z+SCPb6-T5Hc__n+x=ykg-u9vn4b4GXuww@mail.gmail.com/
[2] 
https://lore.kernel.org/loongarch/xyrcgkl7ud5pgh4h5yjyejz646bc22fnnwxahaoafqvnqintf3@mdhtfaybai67/

Thanks,
Tiezhu

Re: [PATCH v1 2/3] objtool/LoongArch: Fix unreachable instruction warnings about EFISTUB

[Tiezhu Yang]

On 2025/9/1 下午4:19, Peter Zijlstra wrote:
> On Mon, Sep 01, 2025 at 03:21:55PM +0800, Tiezhu Yang wrote:
>> When compiling with LLVM and CONFIG_LTO_CLANG is set, there exist the
>> following objtool warnings:
>>
>>    vmlinux.o: warning: objtool: .head.text+0x0: unreachable instruction
>>    vmlinux.o: warning: objtool: .head.text+0x18: unreachable instruction
>>    vmlinux.o: warning: objtool: .head.text+0x38: unreachable instruction
>>    vmlinux.o: warning: objtool: .head.text+0x3c: unreachable instruction
>>    vmlinux.o: warning: objtool: .head.text+0x40: unreachable instruction
>>    vmlinux.o: warning: objtool: .head.text+0x44: unreachable instruction
>>    vmlinux.o: warning: objtool: .head.text+0x54: unreachable instruction
>>    vmlinux.o: warning: objtool: .head.text+0x58: unreachable instruction
>>    vmlinux.o: warning: objtool: .head.text+0x6c: unreachable instruction
>>    vmlinux.o: warning: objtool: .head.text+0x84: unreachable instruction
>>    vmlinux.o: warning: objtool: .head.text+0x94: unreachable instruction
>>    vmlinux.o: warning: objtool: .head.text+0x9c: unreachable instruction
>>    vmlinux.o: warning: objtool: .head.text+0xc4: unreachable instruction
>>    vmlinux.o: warning: objtool: .head.text+0xf8: unreachable instruction
>>    vmlinux.o: warning: objtool: .head.text+0xfc: unreachable instruction
>>    vmlinux.o: warning: objtool: .head.text+0x104: unreachable instruction
>>    vmlinux.o: warning: objtool: .head.text+0x10c: unreachable instruction
>>    vmlinux.o: warning: objtool: .head.text+0x11c: unreachable instruction
>>    vmlinux.o: warning: objtool: .head.text+0x120: unreachable instruction
>>    vmlinux.o: warning: objtool: .head.text+0x124: unreachable instruction
>>    vmlinux.o: warning: objtool: .head.text+0x144: unreachable instruction
>>
>> The instructions in the .head.text section are related with EFISTUB,
>> they are image header and can be ignored by objtool, so just check the
>> section name in ignore_unreachable_insn() to ignore it.
> 
> I am confused; why do the efi/libstub functions generate this error?
> 
> Is this zboot-header.S perhaps? Why can't we properly annotate that
> file?

This is arch/loongarch/kernel/head.S.

There is "OBJECT_FILES_NON_STANDARD_head.o := y" in Makefile
to skip objtool checking for head.o, but OBJECT_FILES_NON_STANDARD
does not work for link time validation of vmlinux.o.

At the beginning, give UNWIND_HINT_UNDEFINED for these instructions,
but there is an argument in the previous RFC [1]:

"The efi header is completely not code, the annotations are very strange."

Josh suggested to do something to put these instructions in the data
section, but as said in the previous reply, it needs to modify the link
process and seems too complicated and expensive for this warning to some
extent.

So I did this change for objtool.

[1] 
https://lore.kernel.org/loongarch/CAAhV-H7NNtH-oaqMsN5=2c+EdF0-dy5mxcsO=_KFGWqb-FZj_w@mail.gmail.com/
[2] 
https://lore.kernel.org/loongarch/l7l2ik5b2inhwbxmlae7ozrlxi7hbdjbrhjsrykjgotlhflah6@jebephhvtxki/

Thanks,
Tiezhu

Re: [PATCH v1 0/3] Fix objtool warnings if LTO is enabled for LoongArch (Part 2)

[Huacai Chen]

On Mon, Sep 1, 2025 at 3:22 PM Tiezhu Yang <yangtiezhu@loongson.cn> wrote:
>
> The previous patches [1] [2] are to fix most of the warnings (total 3030):
>
>   sibling call from callable instruction with modified stack frame
>
> This series is a follow up to fix 2 kinds of warnings (total 24), it only
> touches the objtool and LoongArch related code:
>
>   falls through to next function
>   unreachable instruction
This series seems the best solution from my point of view. So if no
one has objections, I will take it.

Huacai

>
> With this series, there is only 1 kind of warning (total 3), it does not
> only touch the objtool and LoongArch related code:
>
>   missing __noreturn in .c/.h or NORETURN() in noreturns.h
>
> In order to silence the above warnings, it needs to change the related
> code to give the functions __noreturn attribute, and have a NORETURN()
> annotation in tools/objtool/noreturns.h. IMO, it will touch all of the
> archs and the generic code, so this needs much more work to avoid the
> side effect or regression, once it is done I will send out the patch.
>
> Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a47bc954cf0e [1]
> Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5dfea6644d20 [2]
>
> Tiezhu Yang (3):
>   objtool/LoongArch: Fix fall through warning about efi_boot_kernel()
>   objtool/LoongArch: Fix unreachable instruction warnings about EFISTUB
>   LoongArch: Fix unreachable instruction warnings about entry functions
>
>  arch/loongarch/kernel/Makefile | 2 --
>  arch/loongarch/kernel/head.S   | 6 ++----
>  tools/objtool/check.c          | 8 ++++++++
>  3 files changed, 10 insertions(+), 6 deletions(-)
>
> --
> 2.42.0
>

Re: [PATCH v1 1/3] objtool/LoongArch: Fix fall through warning about efi_boot_kernel()

[Josh Poimboeuf]

On Mon, Sep 01, 2025 at 04:31:36PM +0800, Tiezhu Yang wrote:
> On 2025/9/1 下午4:16, Peter Zijlstra wrote:
> > On Mon, Sep 01, 2025 at 03:21:54PM +0800, Tiezhu Yang 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.
> > > 
> > > At the beginning, try to do something to make efi_boot_kernel() ends with
> > > an unconditional jump instruction, but it is not a proper way.
> > > 
> > > After more analysis, one simple way is to ignore these EFISTUB functions
> > > in validate_branch() of objtool since they are useless for stack unwinder.
> > > 
> > 
> > This is drivers/firmware/efi/libstub/loongarch.c:efi_boot_kernel(),
> > right?
> > 
> > Why not simply do something like:
> > 
> > diff --git a/drivers/firmware/efi/libstub/loongarch.c b/drivers/firmware/efi/libstub/loongarch.c
> > index 3782d0a187d1..082611a5f1f0 100644
> > --- a/drivers/firmware/efi/libstub/loongarch.c
> > +++ b/drivers/firmware/efi/libstub/loongarch.c
> > @@ -81,4 +81,5 @@ 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);
> > +	BUG();
> >   }
> 
> At the beginning, I did the above change, but no effect.
> 
> The first thing is to remove the attribute __noreturn for
> real_kernel_entry(), otherwise the compiler can not generate
> instructions after that.
> 
> But there is an argument in the previous RFC [1]:
> 
> "From my point of view this is incorrect, this function is indeed a
> noreturn function, and this modification makes LoongArch different to
> other architectures."
> 
> Josh suggested to do something so that the EFI stub code isn't linked into
> vmlinux.o [2], it needs to modify the link process and seems too
> complicated and expensive for this warning to some extent.
> 
> So I did this change for objtool.

I don't like adding these workarounds to objtool.  Is it really that
complicated to link efistub separately?  That seems like the proper
design.  vmlinux.o should only have real kernel code.

-- 
Josh

Re: [PATCH v1 2/3] objtool/LoongArch: Fix unreachable instruction warnings about EFISTUB

[Josh Poimboeuf]

On Mon, Sep 01, 2025 at 04:39:29PM +0800, Tiezhu Yang wrote:
> On 2025/9/1 下午4:19, Peter Zijlstra wrote:
> > On Mon, Sep 01, 2025 at 03:21:55PM +0800, Tiezhu Yang wrote:
> > > When compiling with LLVM and CONFIG_LTO_CLANG is set, there exist the
> > > following objtool warnings:
> > > 
> > >    vmlinux.o: warning: objtool: .head.text+0x0: unreachable instruction
> > >    vmlinux.o: warning: objtool: .head.text+0x18: unreachable instruction
> > >    vmlinux.o: warning: objtool: .head.text+0x38: unreachable instruction
> > >    vmlinux.o: warning: objtool: .head.text+0x3c: unreachable instruction
> > >    vmlinux.o: warning: objtool: .head.text+0x40: unreachable instruction
> > >    vmlinux.o: warning: objtool: .head.text+0x44: unreachable instruction
> > >    vmlinux.o: warning: objtool: .head.text+0x54: unreachable instruction
> > >    vmlinux.o: warning: objtool: .head.text+0x58: unreachable instruction
> > >    vmlinux.o: warning: objtool: .head.text+0x6c: unreachable instruction
> > >    vmlinux.o: warning: objtool: .head.text+0x84: unreachable instruction
> > >    vmlinux.o: warning: objtool: .head.text+0x94: unreachable instruction
> > >    vmlinux.o: warning: objtool: .head.text+0x9c: unreachable instruction
> > >    vmlinux.o: warning: objtool: .head.text+0xc4: unreachable instruction
> > >    vmlinux.o: warning: objtool: .head.text+0xf8: unreachable instruction
> > >    vmlinux.o: warning: objtool: .head.text+0xfc: unreachable instruction
> > >    vmlinux.o: warning: objtool: .head.text+0x104: unreachable instruction
> > >    vmlinux.o: warning: objtool: .head.text+0x10c: unreachable instruction
> > >    vmlinux.o: warning: objtool: .head.text+0x11c: unreachable instruction
> > >    vmlinux.o: warning: objtool: .head.text+0x120: unreachable instruction
> > >    vmlinux.o: warning: objtool: .head.text+0x124: unreachable instruction
> > >    vmlinux.o: warning: objtool: .head.text+0x144: unreachable instruction
> > > 
> > > The instructions in the .head.text section are related with EFISTUB,
> > > they are image header and can be ignored by objtool, so just check the
> > > section name in ignore_unreachable_insn() to ignore it.
> > 
> > I am confused; why do the efi/libstub functions generate this error?
> > 
> > Is this zboot-header.S perhaps? Why can't we properly annotate that
> > file?
> 
> This is arch/loongarch/kernel/head.S.
> 
> There is "OBJECT_FILES_NON_STANDARD_head.o := y" in Makefile
> to skip objtool checking for head.o, but OBJECT_FILES_NON_STANDARD
> does not work for link time validation of vmlinux.o.
> 
> At the beginning, give UNWIND_HINT_UNDEFINED for these instructions,
> but there is an argument in the previous RFC [1]:
> 
> "The efi header is completely not code, the annotations are very strange."
> 
> Josh suggested to do something to put these instructions in the data
> section, but as said in the previous reply, it needs to modify the link
> process and seems too complicated and expensive for this warning to some
> extent.
> 
> So I did this change for objtool.

I don't like this workaround either, how exactly is it complicated and
expensive to put the data in a data section?

-- 
Josh

Re: [PATCH v1 3/3] LoongArch: Fix unreachable instruction warnings about entry functions

[Josh Poimboeuf]

On Mon, Sep 01, 2025 at 03:21:56PM +0800, Tiezhu Yang wrote:
> +++ b/arch/loongarch/kernel/Makefile
> @@ -3,8 +3,6 @@
>  # Makefile for the Linux/LoongArch kernel.
>  #
>  
> -OBJECT_FILES_NON_STANDARD_head.o := y
> -
>  always-$(KBUILD_BUILTIN)	:= vmlinux.lds
>  
>  obj-y		+= head.o cpu-probe.o cacheinfo.o env.o setup.o entry.o genex.o \
> diff --git a/arch/loongarch/kernel/head.S b/arch/loongarch/kernel/head.S
> index e3865e92a917..a11880f3a7e1 100644
> --- a/arch/loongarch/kernel/head.S
> +++ b/arch/loongarch/kernel/head.S
> @@ -42,6 +42,7 @@ SYM_DATA(kernel_fsize, .long _kernel_fsize);
>  	.align 12
>  
>  SYM_CODE_START(kernel_entry)			# kernel entry point
> +	UNWIND_HINT_UNDEFINED

Should this not be UNWIND_HINT_END_OF_STACK?

I notice Loongarch doesn't seem to use that anywhere.  How does any ORC
unwind succeed?  UNWIND_HINT_UNDEFINED sets an error condition which
should cause a livepatch transition to stall.

-- 
Josh

Re: [PATCH v1 3/3] LoongArch: Fix unreachable instruction warnings about entry functions

[Jinyang He]

On 2025-09-04 03:22, Josh Poimboeuf wrote:

> On Mon, Sep 01, 2025 at 03:21:56PM +0800, Tiezhu Yang wrote:
>> +++ b/arch/loongarch/kernel/Makefile
>> @@ -3,8 +3,6 @@
>>   # Makefile for the Linux/LoongArch kernel.
>>   #
>>   
>> -OBJECT_FILES_NON_STANDARD_head.o := y
>> -
>>   always-$(KBUILD_BUILTIN)	:= vmlinux.lds
>>   
>>   obj-y		+= head.o cpu-probe.o cacheinfo.o env.o setup.o entry.o genex.o \
>> diff --git a/arch/loongarch/kernel/head.S b/arch/loongarch/kernel/head.S
>> index e3865e92a917..a11880f3a7e1 100644
>> --- a/arch/loongarch/kernel/head.S
>> +++ b/arch/loongarch/kernel/head.S
>> @@ -42,6 +42,7 @@ SYM_DATA(kernel_fsize, .long _kernel_fsize);
>>   	.align 12
>>   
>>   SYM_CODE_START(kernel_entry)			# kernel entry point
>> +	UNWIND_HINT_UNDEFINED
> Should this not be UNWIND_HINT_END_OF_STACK?
>
> I notice Loongarch doesn't seem to use that anywhere.  How does any ORC
> unwind succeed?
IIRC, unwinder stops when fail when call __kernel_text_address(bt_address),
or success when call 
arch/loongarch/kernel/unwind_orc.c::is_entry_func(bt_address).
> UNWIND_HINT_UNDEFINED sets an error condition which
> should cause a livepatch transition to stall.
>

Re: [PATCH v1 1/3] objtool/LoongArch: Fix fall through warning about efi_boot_kernel()

[Tiezhu Yang]

On 2025/9/4 上午3:17, Josh Poimboeuf wrote:
> On Mon, Sep 01, 2025 at 04:31:36PM +0800, Tiezhu Yang wrote:
>> On 2025/9/1 下午4:16, Peter Zijlstra wrote:
>>> On Mon, Sep 01, 2025 at 03:21:54PM +0800, Tiezhu Yang wrote:
>>>> When compiling with LLVM and CONFIG_LTO_CLANG is set, there exists
>>>> the following objtool warning:

...

>> Josh suggested to do something so that the EFI stub code isn't linked into
>> vmlinux.o [2], it needs to modify the link process and seems too
>> complicated and expensive for this warning to some extent.
>>
>> So I did this change for objtool.
> 
> I don't like adding these workarounds to objtool.  Is it really that
> complicated to link efistub separately?  That seems like the proper
> design.  vmlinux.o should only have real kernel code.

OK, I see. If this is the only proper direction, I will do it
in the next version.

Thanks,
Tiezhu

Re: [PATCH v1 1/3] objtool/LoongArch: Fix fall through warning about efi_boot_kernel()

[Huacai Chen]

Hi, Josh,

On Thu, Sep 4, 2025 at 3:17 AM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>
> On Mon, Sep 01, 2025 at 04:31:36PM +0800, Tiezhu Yang wrote:
> > On 2025/9/1 下午4:16, Peter Zijlstra wrote:
> > > On Mon, Sep 01, 2025 at 03:21:54PM +0800, Tiezhu Yang 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.
> > > >
> > > > At the beginning, try to do something to make efi_boot_kernel() ends with
> > > > an unconditional jump instruction, but it is not a proper way.
> > > >
> > > > After more analysis, one simple way is to ignore these EFISTUB functions
> > > > in validate_branch() of objtool since they are useless for stack unwinder.
> > > >
> > >
> > > This is drivers/firmware/efi/libstub/loongarch.c:efi_boot_kernel(),
> > > right?
> > >
> > > Why not simply do something like:
> > >
> > > diff --git a/drivers/firmware/efi/libstub/loongarch.c b/drivers/firmware/efi/libstub/loongarch.c
> > > index 3782d0a187d1..082611a5f1f0 100644
> > > --- a/drivers/firmware/efi/libstub/loongarch.c
> > > +++ b/drivers/firmware/efi/libstub/loongarch.c
> > > @@ -81,4 +81,5 @@ 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);
> > > +   BUG();
> > >   }
> >
> > At the beginning, I did the above change, but no effect.
> >
> > The first thing is to remove the attribute __noreturn for
> > real_kernel_entry(), otherwise the compiler can not generate
> > instructions after that.
> >
> > But there is an argument in the previous RFC [1]:
> >
> > "From my point of view this is incorrect, this function is indeed a
> > noreturn function, and this modification makes LoongArch different to
> > other architectures."
> >
> > Josh suggested to do something so that the EFI stub code isn't linked into
> > vmlinux.o [2], it needs to modify the link process and seems too
> > complicated and expensive for this warning to some extent.
> >
> > So I did this change for objtool.
>
> I don't like adding these workarounds to objtool.  Is it really that
> complicated to link efistub separately?  That seems like the proper
> design.  vmlinux.o should only have real kernel code.
I don't think this is just a "workaround", ARM64, RISC-V and LoongArch
share the same logic in efistub which may be different from X86. When
ARM64 and RISC-V add objtool support, they will also need to ignore
the __efistub_ functions.

The other patch is similar.


Huacai

>
> --
> Josh

Re: [PATCH v1 2/3] objtool/LoongArch: Fix unreachable instruction warnings about EFISTUB

[Tiezhu Yang]

On 2025/9/4 上午3:19, Josh Poimboeuf wrote:
> On Mon, Sep 01, 2025 at 04:39:29PM +0800, Tiezhu Yang wrote:
>> On 2025/9/1 下午4:19, Peter Zijlstra wrote:
>>> On Mon, Sep 01, 2025 at 03:21:55PM +0800, Tiezhu Yang wrote:
>>>> When compiling with LLVM and CONFIG_LTO_CLANG is set, there exist the
>>>> following objtool warnings:

...

>> Josh suggested to do something to put these instructions in the data
>> section, but as said in the previous reply, it needs to modify the link
>> process and seems too complicated and expensive for this warning to some
>> extent.
>>
>> So I did this change for objtool.
> 
> I don't like this workaround either, how exactly is it complicated and
> expensive to put the data in a data section?

I can put them in a data section in the next version, this is
reasonable.

Thanks,
Tiezhu

Re: [PATCH v1 2/3] objtool/LoongArch: Fix unreachable instruction warnings about EFISTUB

[Huacai Chen]

On Thu, Sep 4, 2025 at 10:18 AM Tiezhu Yang <yangtiezhu@loongson.cn> wrote:
>
> On 2025/9/4 上午3:19, Josh Poimboeuf wrote:
> > On Mon, Sep 01, 2025 at 04:39:29PM +0800, Tiezhu Yang wrote:
> >> On 2025/9/1 下午4:19, Peter Zijlstra wrote:
> >>> On Mon, Sep 01, 2025 at 03:21:55PM +0800, Tiezhu Yang wrote:
> >>>> When compiling with LLVM and CONFIG_LTO_CLANG is set, there exist the
> >>>> following objtool warnings:
>
> ...
>
> >> Josh suggested to do something to put these instructions in the data
> >> section, but as said in the previous reply, it needs to modify the link
> >> process and seems too complicated and expensive for this warning to some
> >> extent.
> >>
> >> So I did this change for objtool.
> >
> > I don't like this workaround either, how exactly is it complicated and
> > expensive to put the data in a data section?
>
> I can put them in a data section in the next version, this is
> reasonable.
No, from the ARM64 and RISC-V design, we can put jump instructions in
the HEAD section, and this is what Jiaxun wants to do. Changing to a
data section is not reasonable.

Huacai

>
> Thanks,
> Tiezhu
>

Re: [PATCH v1 3/3] LoongArch: Fix unreachable instruction warnings about entry functions

[Tiezhu Yang]

On 2025/9/4 上午3:22, Josh Poimboeuf wrote:
> On Mon, Sep 01, 2025 at 03:21:56PM +0800, Tiezhu Yang wrote:
>> +++ b/arch/loongarch/kernel/Makefile
>> @@ -3,8 +3,6 @@
>>   # Makefile for the Linux/LoongArch kernel.
>>   #
>>   
>> -OBJECT_FILES_NON_STANDARD_head.o := y
>> -
>>   always-$(KBUILD_BUILTIN)	:= vmlinux.lds
>>   
>>   obj-y		+= head.o cpu-probe.o cacheinfo.o env.o setup.o entry.o genex.o \
>> diff --git a/arch/loongarch/kernel/head.S b/arch/loongarch/kernel/head.S
>> index e3865e92a917..a11880f3a7e1 100644
>> --- a/arch/loongarch/kernel/head.S
>> +++ b/arch/loongarch/kernel/head.S
>> @@ -42,6 +42,7 @@ SYM_DATA(kernel_fsize, .long _kernel_fsize);
>>   	.align 12
>>   
>>   SYM_CODE_START(kernel_entry)			# kernel entry point
>> +	UNWIND_HINT_UNDEFINED
> 
> Should this not be UNWIND_HINT_END_OF_STACK?

Yes, makes sense, will do it in the next version.

> I notice Loongarch doesn't seem to use that anywhere.  How does any ORC
> unwind succeed?  UNWIND_HINT_UNDEFINED sets an error condition which
> should cause a livepatch transition to stall.

Actually, kernel_entry() or smpboot_entry() is recognized as the last
frame, because at this point is_entry_func() is true and 
state->stack_info.type = STACK_TYPE_UNKNOWN in unwind_next_frame() of
arch/loongarch/kernel/unwind_orc.c.

Call Trace:
[<90000000031a36b4>] show_stack+0x5c/0x180
[<900000000319d4b0>] dump_stack_lvl+0x6c/0x9c
[<900000000458d3e0>] nmi_cpu_backtrace+0x160/0x168
[<90000000031a3b6c>] handle_backtrace+0xc/0x40
[<90000000032b1078>] __flush_smp_call_function_queue+0xd0/0x330
[<90000000031aec40>] loongson_ipi_interrupt+0xb0/0x168
[<900000000325b4d4>] __handle_irq_event_percpu+0x54/0x1a8
[<900000000325b63c>] handle_irq_event_percpu+0x14/0x80
[<9000000003262a48>] handle_percpu_irq+0x50/0xa0
[<900000000325aad4>] generic_handle_domain_irq+0x2c/0x80
[<9000000003bc4d24>] handle_cpu_irq+0x64/0xa0
[<90000000045a350c>] handle_loongarch_irq+0x2c/0x48
[<90000000045a35e4>] do_vint+0xbc/0xe0
[<90000000031a1624>] handle_vint+0x144/0x1e4
[<900000000321e2e8>] _nohz_idle_balance.isra.0+0x230/0x3a0
[<90000000031cd004>] handle_softirqs+0x10c/0x298
[<90000000031cd2e8>] __irq_exit_rcu+0x100/0x160
[<90000000045a35a4>] do_vint+0x7c/0xe0
[<90000000045a55cc>] idle_exit+0x0/0x4
[<90000000045a55d8>] arch_cpu_idle+0x8/0x30
[<90000000045a5698>] default_idle_call+0x18/0x50
[<90000000032250b0>] do_idle+0xb8/0x130
[<9000000003225374>] cpu_startup_entry+0x2c/0x38
[<90000000045a6240>] kernel_entry_end+0xdc/0xe0
[<90000000045c0d44>] start_kernel+0x65c/0x660
[<90000000045a60f0>] kernel_entry+0xf0/0xf8

Thanks,
Tiezhu

Re: [PATCH v1 2/3] objtool/LoongArch: Fix unreachable instruction warnings about EFISTUB

[Tiezhu Yang]

On 2025/9/4 上午10:21, Huacai Chen wrote:
> On Thu, Sep 4, 2025 at 10:18 AM Tiezhu Yang <yangtiezhu@loongson.cn> wrote:
>>
>> On 2025/9/4 上午3:19, Josh Poimboeuf wrote:
>>> On Mon, Sep 01, 2025 at 04:39:29PM +0800, Tiezhu Yang wrote:
>>>> On 2025/9/1 下午4:19, Peter Zijlstra wrote:
>>>>> On Mon, Sep 01, 2025 at 03:21:55PM +0800, Tiezhu Yang wrote:
>>>>>> When compiling with LLVM and CONFIG_LTO_CLANG is set, there exist the
>>>>>> following objtool warnings:
>>
>> ...
>>
>>>> Josh suggested to do something to put these instructions in the data
>>>> section, but as said in the previous reply, it needs to modify the link
>>>> process and seems too complicated and expensive for this warning to some
>>>> extent.
>>>>
>>>> So I did this change for objtool.
>>>
>>> I don't like this workaround either, how exactly is it complicated and
>>> expensive to put the data in a data section?
>>
>> I can put them in a data section in the next version, this is
>> reasonable.
> No, from the ARM64 and RISC-V design, we can put jump instructions in
> the HEAD section, and this is what Jiaxun wants to do. Changing to a
> data section is not reasonable.

ARM64, RISC-V and LoongArch share the same logic in efistub:

$ grep -r "libstub/lib.a" arch/*/Makefile
arch/arm64/Makefile:libs-$(CONFIG_EFI_STUB) += 
$(objtree)/drivers/firmware/efi/libstub/lib.a
arch/loongarch/Makefile:libs-$(CONFIG_EFI_STUB) += 
$(objtree)/drivers/firmware/efi/libstub/lib.a
arch/riscv/Makefile:libs-$(CONFIG_EFI_STUB) += 
$(objtree)/drivers/firmware/efi/libstub/lib.a

If we can not put the these data to a data section, then we can not
link efistub separately, because if remove the following code in
arch/loongarch/Makefile:

libs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a

there exists the following build error:

    LD      vmlinux.o
   OBJCOPY modules.builtin.modinfo
   GEN     modules.builtin
   GEN     .vmlinux.objs
   MODPOST Module.symvers
   UPD     include/generated/utsversion.h
   CC      init/version-timestamp.o
   KSYMS   .tmp_vmlinux0.kallsyms.S
   AS      .tmp_vmlinux0.kallsyms.o
   LD      .tmp_vmlinux1
ld: arch/loongarch/kernel/head.o: in function `pe_header':
(.head.text+0x68): undefined reference to `__efistub_efi_pe_entry'

What should to do in the next step? I am looking forward to your
final conclusion.

Thanks,
Tiezhu

Re: [PATCH v1 2/3] objtool/LoongArch: Fix unreachable instruction warnings about EFISTUB

[Huacai Chen]

On Thu, Sep 4, 2025 at 11:50 AM Tiezhu Yang <yangtiezhu@loongson.cn> wrote:
>
> On 2025/9/4 上午10:21, Huacai Chen wrote:
> > On Thu, Sep 4, 2025 at 10:18 AM Tiezhu Yang <yangtiezhu@loongson.cn> wrote:
> >>
> >> On 2025/9/4 上午3:19, Josh Poimboeuf wrote:
> >>> On Mon, Sep 01, 2025 at 04:39:29PM +0800, Tiezhu Yang wrote:
> >>>> On 2025/9/1 下午4:19, Peter Zijlstra wrote:
> >>>>> On Mon, Sep 01, 2025 at 03:21:55PM +0800, Tiezhu Yang wrote:
> >>>>>> When compiling with LLVM and CONFIG_LTO_CLANG is set, there exist the
> >>>>>> following objtool warnings:
> >>
> >> ...
> >>
> >>>> Josh suggested to do something to put these instructions in the data
> >>>> section, but as said in the previous reply, it needs to modify the link
> >>>> process and seems too complicated and expensive for this warning to some
> >>>> extent.
> >>>>
> >>>> So I did this change for objtool.
> >>>
> >>> I don't like this workaround either, how exactly is it complicated and
> >>> expensive to put the data in a data section?
> >>
> >> I can put them in a data section in the next version, this is
> >> reasonable.
> > No, from the ARM64 and RISC-V design, we can put jump instructions in
> > the HEAD section, and this is what Jiaxun wants to do. Changing to a
> > data section is not reasonable.
>
> ARM64, RISC-V and LoongArch share the same logic in efistub:
>
> $ grep -r "libstub/lib.a" arch/*/Makefile
> arch/arm64/Makefile:libs-$(CONFIG_EFI_STUB) +=
> $(objtree)/drivers/firmware/efi/libstub/lib.a
> arch/loongarch/Makefile:libs-$(CONFIG_EFI_STUB) +=
> $(objtree)/drivers/firmware/efi/libstub/lib.a
> arch/riscv/Makefile:libs-$(CONFIG_EFI_STUB) +=
> $(objtree)/drivers/firmware/efi/libstub/lib.a
>
> If we can not put the these data to a data section, then we can not
> link efistub separately, because if remove the following code in
> arch/loongarch/Makefile:
>
> libs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a
>
> there exists the following build error:
>
>     LD      vmlinux.o
>    OBJCOPY modules.builtin.modinfo
>    GEN     modules.builtin
>    GEN     .vmlinux.objs
>    MODPOST Module.symvers
>    UPD     include/generated/utsversion.h
>    CC      init/version-timestamp.o
>    KSYMS   .tmp_vmlinux0.kallsyms.S
>    AS      .tmp_vmlinux0.kallsyms.o
>    LD      .tmp_vmlinux1
> ld: arch/loongarch/kernel/head.o: in function `pe_header':
> (.head.text+0x68): undefined reference to `__efistub_efi_pe_entry'
>
> What should to do in the next step? I am looking forward to your
> final conclusion.

This is from RISC-V code.

__HEAD
SYM_CODE_START(_start)
        /*
         * Image header expected by Linux boot-loaders. The image header data
         * structure is described in asm/image.h.
         * Do not modify it without modifying the structure and all bootloaders
         * that expects this header format!!
         */
#ifdef CONFIG_EFI
        /*
         * This instruction decodes to "MZ" ASCII required by UEFI.
         */
        c.li s4,-13
        j _start_kernel
#else
        /* jump to start kernel */
        j _start_kernel
        /* reserved */
        .word 0
#endif

The HEAD section has instructions, if you change it into a data
section then it loses the "x" attribute.

So my conclusion is this series is the correct solution for all
non-x86 archs. We don't need to treat it as "workarounds".

Huacai

>
> Thanks,
> Tiezhu
>

Re: [PATCH v1 3/3] LoongArch: Fix unreachable instruction warnings about entry functions

[Josh Poimboeuf]

On Thu, Sep 04, 2025 at 11:18:28AM +0800, Tiezhu Yang wrote:
> On 2025/9/4 上午3:22, Josh Poimboeuf wrote:
> > On Mon, Sep 01, 2025 at 03:21:56PM +0800, Tiezhu Yang wrote:
> > > +++ b/arch/loongarch/kernel/Makefile
> > > @@ -3,8 +3,6 @@
> > >   # Makefile for the Linux/LoongArch kernel.
> > >   #
> > > -OBJECT_FILES_NON_STANDARD_head.o := y
> > > -
> > >   always-$(KBUILD_BUILTIN)	:= vmlinux.lds
> > >   obj-y		+= head.o cpu-probe.o cacheinfo.o env.o setup.o entry.o genex.o \
> > > diff --git a/arch/loongarch/kernel/head.S b/arch/loongarch/kernel/head.S
> > > index e3865e92a917..a11880f3a7e1 100644
> > > --- a/arch/loongarch/kernel/head.S
> > > +++ b/arch/loongarch/kernel/head.S
> > > @@ -42,6 +42,7 @@ SYM_DATA(kernel_fsize, .long _kernel_fsize);
> > >   	.align 12
> > >   SYM_CODE_START(kernel_entry)			# kernel entry point
> > > +	UNWIND_HINT_UNDEFINED
> > 
> > Should this not be UNWIND_HINT_END_OF_STACK?
> 
> Yes, makes sense, will do it in the next version.
> 
> > I notice Loongarch doesn't seem to use that anywhere.  How does any ORC
> > unwind succeed?  UNWIND_HINT_UNDEFINED sets an error condition which
> > should cause a livepatch transition to stall.
> 
> Actually, kernel_entry() or smpboot_entry() is recognized as the last
> frame, because at this point is_entry_func() is true and
> state->stack_info.type = STACK_TYPE_UNKNOWN in unwind_next_frame() of
> arch/loongarch/kernel/unwind_orc.c.

I think you can get rid of is_entry_func() in favor of just using
UNWIND_HINT_END_OF_STACK at all the entry points.

-- 
Josh

Re: [PATCH v1 1/3] objtool/LoongArch: Fix fall through warning about efi_boot_kernel()

[Josh Poimboeuf]

On Thu, Sep 04, 2025 at 10:17:11AM +0800, Huacai Chen wrote:
> Hi, Josh,
> 
> On Thu, Sep 4, 2025 at 3:17 AM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> >
> > On Mon, Sep 01, 2025 at 04:31:36PM +0800, Tiezhu Yang wrote:
> > > On 2025/9/1 下午4:16, Peter Zijlstra wrote:
> > > > On Mon, Sep 01, 2025 at 03:21:54PM +0800, Tiezhu Yang 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.
> > > > >
> > > > > At the beginning, try to do something to make efi_boot_kernel() ends with
> > > > > an unconditional jump instruction, but it is not a proper way.
> > > > >
> > > > > After more analysis, one simple way is to ignore these EFISTUB functions
> > > > > in validate_branch() of objtool since they are useless for stack unwinder.
> > > > >
> > > >
> > > > This is drivers/firmware/efi/libstub/loongarch.c:efi_boot_kernel(),
> > > > right?
> > > >
> > > > Why not simply do something like:
> > > >
> > > > diff --git a/drivers/firmware/efi/libstub/loongarch.c b/drivers/firmware/efi/libstub/loongarch.c
> > > > index 3782d0a187d1..082611a5f1f0 100644
> > > > --- a/drivers/firmware/efi/libstub/loongarch.c
> > > > +++ b/drivers/firmware/efi/libstub/loongarch.c
> > > > @@ -81,4 +81,5 @@ 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);
> > > > +   BUG();
> > > >   }
> > >
> > > At the beginning, I did the above change, but no effect.
> > >
> > > The first thing is to remove the attribute __noreturn for
> > > real_kernel_entry(), otherwise the compiler can not generate
> > > instructions after that.
> > >
> > > But there is an argument in the previous RFC [1]:
> > >
> > > "From my point of view this is incorrect, this function is indeed a
> > > noreturn function, and this modification makes LoongArch different to
> > > other architectures."
> > >
> > > Josh suggested to do something so that the EFI stub code isn't linked into
> > > vmlinux.o [2], it needs to modify the link process and seems too
> > > complicated and expensive for this warning to some extent.
> > >
> > > So I did this change for objtool.
> >
> > I don't like adding these workarounds to objtool.  Is it really that
> > complicated to link efistub separately?  That seems like the proper
> > design.  vmlinux.o should only have real kernel code.
> I don't think this is just a "workaround", ARM64, RISC-V and LoongArch
> share the same logic in efistub which may be different from X86. When
> ARM64 and RISC-V add objtool support, they will also need to ignore
> the __efistub_ functions.
> 
> The other patch is similar.

Objtool expects/enforces certain rules.  One of them is that vmlinux.o
is proper runtime kernel code.  efistub is not that.

Is there some technical reason why vmlinux.o needs efistub linked in?

-- 
Josh

Re: [PATCH v1 2/3] objtool/LoongArch: Fix unreachable instruction warnings about EFISTUB

[Josh Poimboeuf]

On Thu, Sep 04, 2025 at 11:59:30AM +0800, Huacai Chen wrote:
> On Thu, Sep 4, 2025 at 11:50 AM Tiezhu Yang <yangtiezhu@loongson.cn> wrote:
> >
> > On 2025/9/4 上午10:21, Huacai Chen wrote:
> > > On Thu, Sep 4, 2025 at 10:18 AM Tiezhu Yang <yangtiezhu@loongson.cn> wrote:
> > >>
> > >> On 2025/9/4 上午3:19, Josh Poimboeuf wrote:
> > >>> On Mon, Sep 01, 2025 at 04:39:29PM +0800, Tiezhu Yang wrote:
> > >>>> On 2025/9/1 下午4:19, Peter Zijlstra wrote:
> > >>>>> On Mon, Sep 01, 2025 at 03:21:55PM +0800, Tiezhu Yang wrote:
> > >>>>>> When compiling with LLVM and CONFIG_LTO_CLANG is set, there exist the
> > >>>>>> following objtool warnings:
> > >>
> > >> ...
> > >>
> > >>>> Josh suggested to do something to put these instructions in the data
> > >>>> section, but as said in the previous reply, it needs to modify the link
> > >>>> process and seems too complicated and expensive for this warning to some
> > >>>> extent.
> > >>>>
> > >>>> So I did this change for objtool.
> > >>>
> > >>> I don't like this workaround either, how exactly is it complicated and
> > >>> expensive to put the data in a data section?
> > >>
> > >> I can put them in a data section in the next version, this is
> > >> reasonable.
> > > No, from the ARM64 and RISC-V design, we can put jump instructions in
> > > the HEAD section, and this is what Jiaxun wants to do. Changing to a
> > > data section is not reasonable.
> >
> > ARM64, RISC-V and LoongArch share the same logic in efistub:
> >
> > $ grep -r "libstub/lib.a" arch/*/Makefile
> > arch/arm64/Makefile:libs-$(CONFIG_EFI_STUB) +=
> > $(objtree)/drivers/firmware/efi/libstub/lib.a
> > arch/loongarch/Makefile:libs-$(CONFIG_EFI_STUB) +=
> > $(objtree)/drivers/firmware/efi/libstub/lib.a
> > arch/riscv/Makefile:libs-$(CONFIG_EFI_STUB) +=
> > $(objtree)/drivers/firmware/efi/libstub/lib.a
> >
> > If we can not put the these data to a data section, then we can not
> > link efistub separately, because if remove the following code in
> > arch/loongarch/Makefile:
> >
> > libs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a
> >
> > there exists the following build error:
> >
> >     LD      vmlinux.o
> >    OBJCOPY modules.builtin.modinfo
> >    GEN     modules.builtin
> >    GEN     .vmlinux.objs
> >    MODPOST Module.symvers
> >    UPD     include/generated/utsversion.h
> >    CC      init/version-timestamp.o
> >    KSYMS   .tmp_vmlinux0.kallsyms.S
> >    AS      .tmp_vmlinux0.kallsyms.o
> >    LD      .tmp_vmlinux1
> > ld: arch/loongarch/kernel/head.o: in function `pe_header':
> > (.head.text+0x68): undefined reference to `__efistub_efi_pe_entry'
> >
> > What should to do in the next step? I am looking forward to your
> > final conclusion.
> 
> This is from RISC-V code.
> 
> __HEAD
> SYM_CODE_START(_start)
>         /*
>          * Image header expected by Linux boot-loaders. The image header data
>          * structure is described in asm/image.h.
>          * Do not modify it without modifying the structure and all bootloaders
>          * that expects this header format!!
>          */
> #ifdef CONFIG_EFI
>         /*
>          * This instruction decodes to "MZ" ASCII required by UEFI.
>          */
>         c.li s4,-13
>         j _start_kernel
> #else
>         /* jump to start kernel */
>         j _start_kernel
>         /* reserved */
>         .word 0
> #endif
> 
> The HEAD section has instructions, if you change it into a data
> section then it loses the "x" attribute.
> 
> So my conclusion is this series is the correct solution for all
> non-x86 archs. We don't need to treat it as "workarounds".

Ok.  In that case please put the full justifications for these changes
in the patch descriptions.

-- 
Josh