[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

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 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 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 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 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 1/3] objtool/LoongArch: Fix fall through warning about efi_boot_kernel()

[Huacai Chen]

Hi, Josh,

On Fri, Sep 5, 2025 at 1:26 AM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>
> 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?
I think so. For example, EFISTUB prefer to directly use screen_info
that defined in vmlinux, see the comments in
drivers/firmware/efi/libstub/screen_info.c:

/*
 * There are two ways of populating the core kernel's struct
screen_info via the stub:
 * - using a configuration table, like below, which relies on the EFI init code
 *   to locate the table and copy the contents;
 * - by linking directly to the core kernel's copy of the global symbol.
 *
 * The latter is preferred because it makes the EFIFB earlycon available very
 * early, but it only works if the EFI stub is part of the core kernel image
 * itself. The zboot decompressor can only use the configuration table
 * approach.
 */

Huacai

>
> --
> Josh

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

[Tiezhu Yang]

Hi Josh,

On 2025/9/5 下午12:33, Huacai Chen wrote:
> Hi, Josh,
> 
> On Fri, Sep 5, 2025 at 1:26 AM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>>
>> On Thu, Sep 04, 2025 at 10:17:11AM +0800, Huacai Chen wrote:

...

>> Is there some technical reason why vmlinux.o needs efistub linked in?
> I think so. For example, EFISTUB prefer to directly use screen_info
> that defined in vmlinux, see the comments in
> drivers/firmware/efi/libstub/screen_info.c:
> 
> /*
>   * There are two ways of populating the core kernel's struct
> screen_info via the stub:
>   * - using a configuration table, like below, which relies on the EFI init code
>   *   to locate the table and copy the contents;
>   * - by linking directly to the core kernel's copy of the global symbol.
>   *
>   * The latter is preferred because it makes the EFIFB earlycon available very
>   * early, but it only works if the EFI stub is part of the core kernel image
>   * itself. The zboot decompressor can only use the configuration table
>   * approach.
>   */

I wonder what is the final conclusion.

(1) For patch #1 and #2, keep the code as is and just update
the commit message.

(2) For patch #3, replace UNWIND_HINT_UNDEFINED with
UNWIND_HINT_END_OF_STACK and remove is_entry_func().

If there are any more comments, please let me know.

Thanks,
Tiezhu

[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

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 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 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 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 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 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

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

[Josh Poimboeuf]

On Thu, Sep 04, 2025 at 10:39:30AM -0700, Josh Poimboeuf wrote:
> On Thu, Sep 04, 2025 at 11:59:30AM +0800, Huacai Chen wrote:
> > 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.

Actually, the "x" attribute isn't needed for vmlinux.  The vmlinux
linker script places it in the text region regardless.

Moving the data to a data section should be really simple, something
like the below.

And yes, even the above RISC-V code can be in a data section.  Those
instructions are part of the 'struct riscv_image_header' data structure.

diff --git a/arch/loongarch/kernel/head.S b/arch/loongarch/kernel/head.S
index e3865e92a917a..c42500d9fad81 100644
--- a/arch/loongarch/kernel/head.S
+++ b/arch/loongarch/kernel/head.S
@@ -17,7 +17,7 @@
 
 #include "efi-header.S"
 
-	__HEAD
+	__HEADDATA
 
 _head:
 	.word	IMAGE_DOS_SIGNATURE	/* "MZ", MS-DOS header */
diff --git a/arch/loongarch/kernel/vmlinux.lds.S b/arch/loongarch/kernel/vmlinux.lds.S
index 08ea921cdec16..fc35ef349aba6 100644
--- a/arch/loongarch/kernel/vmlinux.lds.S
+++ b/arch/loongarch/kernel/vmlinux.lds.S
@@ -38,6 +38,7 @@ SECTIONS
 	. = VMLINUX_LOAD_ADDRESS;
 
 	_text = .;
+	HEAD_DATA_SECTION
 	HEAD_TEXT_SECTION
 
 	. = ALIGN(PECOFF_SEGMENT_ALIGN);
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 6b2311fa41393..c74492e1baa5a 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -629,6 +629,11 @@
 		*(.static_call.text)					\
 		__static_call_text_end = .;
 
+#define HEAD_DATA_SECTION						\
+	.head.data : AT(ADDR(.head.data) - LOAD_OFFSET) {		\
+		KEEP(*(.head.data))					\
+	}
+
 /* Section used for early init (in .S files) */
 #define HEAD_TEXT  KEEP(*(.head.text))
 
diff --git a/include/linux/init.h b/include/linux/init.h
index 331886205049e..fcb02ab3faae2 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -98,6 +98,7 @@
 
 /* For assembly routines */
 #define __HEAD		.section	".head.text","ax"
+#define __HEADDATA	.section	".head.data","aw"
 #define __INIT		.section	".init.text","ax"
 #define __FINIT		.previous
 

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

[Huacai Chen]

Hi, Josh,

On Fri, Sep 5, 2025 at 5:46 AM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>
> On Thu, Sep 04, 2025 at 10:39:30AM -0700, Josh Poimboeuf wrote:
> > On Thu, Sep 04, 2025 at 11:59:30AM +0800, Huacai Chen wrote:
> > > 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.
>
> Actually, the "x" attribute isn't needed for vmlinux.  The vmlinux
> linker script places it in the text region regardless.
>
> Moving the data to a data section should be really simple, something
> like the below.
>
> And yes, even the above RISC-V code can be in a data section.  Those
> instructions are part of the 'struct riscv_image_header' data structure.
This may work but also look strange (code in data section), it is more
like a "workaround". :)

Huacai

>
> diff --git a/arch/loongarch/kernel/head.S b/arch/loongarch/kernel/head.S
> index e3865e92a917a..c42500d9fad81 100644
> --- a/arch/loongarch/kernel/head.S
> +++ b/arch/loongarch/kernel/head.S
> @@ -17,7 +17,7 @@
>
>  #include "efi-header.S"
>
> -       __HEAD
> +       __HEADDATA
>
>  _head:
>         .word   IMAGE_DOS_SIGNATURE     /* "MZ", MS-DOS header */
> diff --git a/arch/loongarch/kernel/vmlinux.lds.S b/arch/loongarch/kernel/vmlinux.lds.S
> index 08ea921cdec16..fc35ef349aba6 100644
> --- a/arch/loongarch/kernel/vmlinux.lds.S
> +++ b/arch/loongarch/kernel/vmlinux.lds.S
> @@ -38,6 +38,7 @@ SECTIONS
>         . = VMLINUX_LOAD_ADDRESS;
>
>         _text = .;
> +       HEAD_DATA_SECTION
>         HEAD_TEXT_SECTION
>
>         . = ALIGN(PECOFF_SEGMENT_ALIGN);
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index 6b2311fa41393..c74492e1baa5a 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -629,6 +629,11 @@
>                 *(.static_call.text)                                    \
>                 __static_call_text_end = .;
>
> +#define HEAD_DATA_SECTION                                              \
> +       .head.data : AT(ADDR(.head.data) - LOAD_OFFSET) {               \
> +               KEEP(*(.head.data))                                     \
> +       }
> +
>  /* Section used for early init (in .S files) */
>  #define HEAD_TEXT  KEEP(*(.head.text))
>
> diff --git a/include/linux/init.h b/include/linux/init.h
> index 331886205049e..fcb02ab3faae2 100644
> --- a/include/linux/init.h
> +++ b/include/linux/init.h
> @@ -98,6 +98,7 @@
>
>  /* For assembly routines */
>  #define __HEAD         .section        ".head.text","ax"
> +#define __HEADDATA     .section        ".head.data","aw"
>  #define __INIT         .section        ".init.text","ax"
>  #define __FINIT                .previous
>
>

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

[Josh Poimboeuf]

On Fri, Sep 05, 2025 at 12:36:16PM +0800, Huacai Chen wrote:
> Hi, Josh,
> 
> On Fri, Sep 5, 2025 at 5:46 AM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> >
> > On Thu, Sep 04, 2025 at 10:39:30AM -0700, Josh Poimboeuf wrote:
> > > On Thu, Sep 04, 2025 at 11:59:30AM +0800, Huacai Chen wrote:
> > > > 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.
> >
> > Actually, the "x" attribute isn't needed for vmlinux.  The vmlinux
> > linker script places it in the text region regardless.
> >
> > Moving the data to a data section should be really simple, something
> > like the below.
> >
> > And yes, even the above RISC-V code can be in a data section.  Those
> > instructions are part of the 'struct riscv_image_header' data structure.
> This may work but also look strange (code in data section), it is more
> like a "workaround". :)

The "strange" part of the code is the intermixing of code and data.  If
they can't be separated, then they are part of a data structure and
belong in a data section.

-- 
Josh

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

[Tiezhu Yang]

On 2025/9/6 上午12:04, Josh Poimboeuf wrote:
> On Fri, Sep 05, 2025 at 12:36:16PM +0800, Huacai Chen wrote:
>> Hi, Josh,
>>
>> On Fri, Sep 5, 2025 at 5:46 AM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>>>
>>> On Thu, Sep 04, 2025 at 10:39:30AM -0700, Josh Poimboeuf wrote:
>>>> On Thu, Sep 04, 2025 at 11:59:30AM +0800, Huacai Chen wrote:
>>>>> 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.
>>>
>>> Actually, the "x" attribute isn't needed for vmlinux.  The vmlinux
>>> linker script places it in the text region regardless.
>>>
>>> Moving the data to a data section should be really simple, something
>>> like the below.
>>>
>>> And yes, even the above RISC-V code can be in a data section.  Those
>>> instructions are part of the 'struct riscv_image_header' data structure.
>> This may work but also look strange (code in data section), it is more
>> like a "workaround". :)
> 
> The "strange" part of the code is the intermixing of code and data.  If
> they can't be separated, then they are part of a data structure and
> belong in a data section.

I tried the following minimal changes, put the image header into
the section .head.data, do not link efistub lib.a into vmlinux.o,
just link efistub lib.a into vmlinux, no other changes, they have
same effect with patch #1 and #2, what do you think?

----->8-----
diff --git a/arch/loongarch/Makefile b/arch/loongarch/Makefile
index a3a9759414f4..919c1970ce14 100644
--- a/arch/loongarch/Makefile
+++ b/arch/loongarch/Makefile
@@ -164,7 +164,6 @@ 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

  drivers-y              += arch/loongarch/crypto/

diff --git a/arch/loongarch/kernel/head.S b/arch/loongarch/kernel/head.S
index e3865e92a917..c42500d9fad8 100644
--- a/arch/loongarch/kernel/head.S
+++ b/arch/loongarch/kernel/head.S
@@ -17,7 +17,7 @@

  #include "efi-header.S"

-       __HEAD
+       __HEADDATA

  _head:
         .word   IMAGE_DOS_SIGNATURE     /* "MZ", MS-DOS header */
diff --git a/arch/loongarch/kernel/vmlinux.lds.S 
b/arch/loongarch/kernel/vmlinux.lds.S
index 08ea921cdec1..fc35ef349aba 100644
--- a/arch/loongarch/kernel/vmlinux.lds.S
+++ b/arch/loongarch/kernel/vmlinux.lds.S
@@ -38,6 +38,7 @@ SECTIONS
         . = VMLINUX_LOAD_ADDRESS;

         _text = .;
+       HEAD_DATA_SECTION
         HEAD_TEXT_SECTION

         . = ALIGN(PECOFF_SEGMENT_ALIGN);
diff --git a/include/asm-generic/vmlinux.lds.h 
b/include/asm-generic/vmlinux.lds.h
index ae2d2359b79e..0f95fb1649f3 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -645,6 +645,14 @@ defined(CONFIG_AUTOFDO_CLANG) || 
defined(CONFIG_PROPELLER_CLANG)
                 *(.static_call.text)                                    \
                 __static_call_text_end = .;

+/* Section used for early init (in .S files) */
+#define HEAD_DATA  KEEP(*(.head.data))
+
+#define HEAD_DATA_SECTION                                              \
+       .head.data : AT(ADDR(.head.data) - LOAD_OFFSET) {               \
+               HEAD_DATA                                               \
+       }
+
  /* Section used for early init (in .S files) */
  #define HEAD_TEXT  KEEP(*(.head.text))

diff --git a/include/linux/init.h b/include/linux/init.h
index a60d32d227ee..4e5be09c42cd 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -98,6 +98,7 @@

  /* For assembly routines */
  #define __HEAD         .section        ".head.text","ax"
+#define __HEADDATA     .section        ".head.data","aw"
  #define __INIT         .section        ".init.text","ax"
  #define __FINIT                .previous

diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index 51367c2bfc21..c664bfb9b15f 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -69,6 +69,12 @@ vmlinux_link()
                 libs="${KBUILD_VMLINUX_LIBS}"
         fi

+       if [ "${SRCARCH}" = "loongarch" ]; then
+               if is_enabled CONFIG_EFI_STUB; then
+                       libs="${libs} drivers/firmware/efi/libstub/lib.a"
+               fi
+       fi
+
         if is_enabled CONFIG_GENERIC_BUILTIN_DTB; then
                 objs="${objs} .builtin-dtbs.o"
         fi

Thanks,
Tiezhu

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

[Huacai Chen]

On Tue, Sep 9, 2025 at 12:00 PM Tiezhu Yang <yangtiezhu@loongson.cn> wrote:
>
> On 2025/9/6 上午12:04, Josh Poimboeuf wrote:
> > On Fri, Sep 05, 2025 at 12:36:16PM +0800, Huacai Chen wrote:
> >> Hi, Josh,
> >>
> >> On Fri, Sep 5, 2025 at 5:46 AM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> >>>
> >>> On Thu, Sep 04, 2025 at 10:39:30AM -0700, Josh Poimboeuf wrote:
> >>>> On Thu, Sep 04, 2025 at 11:59:30AM +0800, Huacai Chen wrote:
> >>>>> 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.
> >>>
> >>> Actually, the "x" attribute isn't needed for vmlinux.  The vmlinux
> >>> linker script places it in the text region regardless.
> >>>
> >>> Moving the data to a data section should be really simple, something
> >>> like the below.
> >>>
> >>> And yes, even the above RISC-V code can be in a data section.  Those
> >>> instructions are part of the 'struct riscv_image_header' data structure.
> >> This may work but also look strange (code in data section), it is more
> >> like a "workaround". :)
> >
> > The "strange" part of the code is the intermixing of code and data.  If
> > they can't be separated, then they are part of a data structure and
> > belong in a data section.
>
> I tried the following minimal changes, put the image header into
> the section .head.data, do not link efistub lib.a into vmlinux.o,
> just link efistub lib.a into vmlinux, no other changes, they have
> same effect with patch #1 and #2, what do you think?
I still don't think we have to put the HEAD into a data section. Yes,
it is a mix of code and data, but the data is read-only so it doesn't
need the "w" attribute (and code needs "x", at least in theory).

From my point of view, the text section is still the best for HEAD.

Huacai

>
> ----->8-----
> diff --git a/arch/loongarch/Makefile b/arch/loongarch/Makefile
> index a3a9759414f4..919c1970ce14 100644
> --- a/arch/loongarch/Makefile
> +++ b/arch/loongarch/Makefile
> @@ -164,7 +164,6 @@ 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
>
>   drivers-y              += arch/loongarch/crypto/
>
> diff --git a/arch/loongarch/kernel/head.S b/arch/loongarch/kernel/head.S
> index e3865e92a917..c42500d9fad8 100644
> --- a/arch/loongarch/kernel/head.S
> +++ b/arch/loongarch/kernel/head.S
> @@ -17,7 +17,7 @@
>
>   #include "efi-header.S"
>
> -       __HEAD
> +       __HEADDATA
>
>   _head:
>          .word   IMAGE_DOS_SIGNATURE     /* "MZ", MS-DOS header */
> diff --git a/arch/loongarch/kernel/vmlinux.lds.S
> b/arch/loongarch/kernel/vmlinux.lds.S
> index 08ea921cdec1..fc35ef349aba 100644
> --- a/arch/loongarch/kernel/vmlinux.lds.S
> +++ b/arch/loongarch/kernel/vmlinux.lds.S
> @@ -38,6 +38,7 @@ SECTIONS
>          . = VMLINUX_LOAD_ADDRESS;
>
>          _text = .;
> +       HEAD_DATA_SECTION
>          HEAD_TEXT_SECTION
>
>          . = ALIGN(PECOFF_SEGMENT_ALIGN);
> diff --git a/include/asm-generic/vmlinux.lds.h
> b/include/asm-generic/vmlinux.lds.h
> index ae2d2359b79e..0f95fb1649f3 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -645,6 +645,14 @@ defined(CONFIG_AUTOFDO_CLANG) ||
> defined(CONFIG_PROPELLER_CLANG)
>                  *(.static_call.text)                                    \
>                  __static_call_text_end = .;
>
> +/* Section used for early init (in .S files) */
> +#define HEAD_DATA  KEEP(*(.head.data))
> +
> +#define HEAD_DATA_SECTION                                              \
> +       .head.data : AT(ADDR(.head.data) - LOAD_OFFSET) {               \
> +               HEAD_DATA                                               \
> +       }
> +
>   /* Section used for early init (in .S files) */
>   #define HEAD_TEXT  KEEP(*(.head.text))
>
> diff --git a/include/linux/init.h b/include/linux/init.h
> index a60d32d227ee..4e5be09c42cd 100644
> --- a/include/linux/init.h
> +++ b/include/linux/init.h
> @@ -98,6 +98,7 @@
>
>   /* For assembly routines */
>   #define __HEAD         .section        ".head.text","ax"
> +#define __HEADDATA     .section        ".head.data","aw"
>   #define __INIT         .section        ".init.text","ax"
>   #define __FINIT                .previous
>
> diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
> index 51367c2bfc21..c664bfb9b15f 100755
> --- a/scripts/link-vmlinux.sh
> +++ b/scripts/link-vmlinux.sh
> @@ -69,6 +69,12 @@ vmlinux_link()
>                  libs="${KBUILD_VMLINUX_LIBS}"
>          fi
>
> +       if [ "${SRCARCH}" = "loongarch" ]; then
> +               if is_enabled CONFIG_EFI_STUB; then
> +                       libs="${libs} drivers/firmware/efi/libstub/lib.a"
> +               fi
> +       fi
> +
>          if is_enabled CONFIG_GENERIC_BUILTIN_DTB; then
>                  objs="${objs} .builtin-dtbs.o"
>          fi
>
> Thanks,
> Tiezhu
>

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

[Josh Poimboeuf]

On Tue, Sep 09, 2025 at 12:10:29PM +0800, Huacai Chen wrote:
> On Tue, Sep 9, 2025 at 12:00 PM Tiezhu Yang <yangtiezhu@loongson.cn> wrote:
> >
> > On 2025/9/6 上午12:04, Josh Poimboeuf wrote:
> > > On Fri, Sep 05, 2025 at 12:36:16PM +0800, Huacai Chen wrote:
> > >> Hi, Josh,
> > >>
> > >> On Fri, Sep 5, 2025 at 5:46 AM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> > >>>
> > >>> On Thu, Sep 04, 2025 at 10:39:30AM -0700, Josh Poimboeuf wrote:
> > >>>> On Thu, Sep 04, 2025 at 11:59:30AM +0800, Huacai Chen wrote:
> > >>>>> 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.
> > >>>
> > >>> Actually, the "x" attribute isn't needed for vmlinux.  The vmlinux
> > >>> linker script places it in the text region regardless.
> > >>>
> > >>> Moving the data to a data section should be really simple, something
> > >>> like the below.
> > >>>
> > >>> And yes, even the above RISC-V code can be in a data section.  Those
> > >>> instructions are part of the 'struct riscv_image_header' data structure.
> > >> This may work but also look strange (code in data section), it is more
> > >> like a "workaround". :)
> > >
> > > The "strange" part of the code is the intermixing of code and data.  If
> > > they can't be separated, then they are part of a data structure and
> > > belong in a data section.
> >
> > I tried the following minimal changes, put the image header into
> > the section .head.data, do not link efistub lib.a into vmlinux.o,
> > just link efistub lib.a into vmlinux, no other changes, they have
> > same effect with patch #1 and #2, what do you think?
> I still don't think we have to put the HEAD into a data section. Yes,
> it is a mix of code and data, but the data is read-only so it doesn't
> need the "w" attribute (and code needs "x", at least in theory).

Then it can be __HEAD_RODATA, with the "w" removed:

#define __HEAD_RODATA	.section	".head.rodata","a"

> From my point of view, the text section is still the best for HEAD.

It belongs in a data section for two reasons:

  1) It's an image header data structure.

  2) We don't want objtool (or any other tooling) to try to validate it
     or otherwise treat it as text during the build.

-- 
Josh

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

[Huacai Chen]

Hi, Josh,

On Wed, Sep 10, 2025 at 12:05 AM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>
> On Tue, Sep 09, 2025 at 12:10:29PM +0800, Huacai Chen wrote:
> > On Tue, Sep 9, 2025 at 12:00 PM Tiezhu Yang <yangtiezhu@loongson.cn> wrote:
> > >
> > > On 2025/9/6 上午12:04, Josh Poimboeuf wrote:
> > > > On Fri, Sep 05, 2025 at 12:36:16PM +0800, Huacai Chen wrote:
> > > >> Hi, Josh,
> > > >>
> > > >> On Fri, Sep 5, 2025 at 5:46 AM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> > > >>>
> > > >>> On Thu, Sep 04, 2025 at 10:39:30AM -0700, Josh Poimboeuf wrote:
> > > >>>> On Thu, Sep 04, 2025 at 11:59:30AM +0800, Huacai Chen wrote:
> > > >>>>> 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.
> > > >>>
> > > >>> Actually, the "x" attribute isn't needed for vmlinux.  The vmlinux
> > > >>> linker script places it in the text region regardless.
> > > >>>
> > > >>> Moving the data to a data section should be really simple, something
> > > >>> like the below.
> > > >>>
> > > >>> And yes, even the above RISC-V code can be in a data section.  Those
> > > >>> instructions are part of the 'struct riscv_image_header' data structure.
> > > >> This may work but also look strange (code in data section), it is more
> > > >> like a "workaround". :)
> > > >
> > > > The "strange" part of the code is the intermixing of code and data.  If
> > > > they can't be separated, then they are part of a data structure and
> > > > belong in a data section.
> > >
> > > I tried the following minimal changes, put the image header into
> > > the section .head.data, do not link efistub lib.a into vmlinux.o,
> > > just link efistub lib.a into vmlinux, no other changes, they have
> > > same effect with patch #1 and #2, what do you think?
> > I still don't think we have to put the HEAD into a data section. Yes,
> > it is a mix of code and data, but the data is read-only so it doesn't
> > need the "w" attribute (and code needs "x", at least in theory).
>
> Then it can be __HEAD_RODATA, with the "w" removed:
>
> #define __HEAD_RODATA   .section        ".head.rodata","a"
>
> > From my point of view, the text section is still the best for HEAD.
>
> It belongs in a data section for two reasons:
>
>   1) It's an image header data structure.
>
>   2) We don't want objtool (or any other tooling) to try to validate it
>      or otherwise treat it as text during the build.
I'm sorry but I insist on my opinion. :)

Yes, there are reasons to put it into a data section, but there are
also reasons to put it into a code section.

1) ARM64, RISC-V and LoongArch have the same style (mix code and data
in __HEAD), I don't want to do something special.

2) __HEAD is used for nearly all archs, except ARM64, RISC-V and
LoongArch, other archs are almost pure code (so they must use a code
section). However, the code in __HEAD is usually not like a regular
function. In other word, if other archs add objtool support, __HEAD
will also probably cause problems.

3) Many archs put __HEAD between __init_begin and __init_end, which
means it is discarded at runtime, stack unwinder is useless for it.

So, ignoring .head.text is not just a workaround for LoongArch, it is
a proper solution for other archs.


Huacai

>
> --
> Josh
>

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

[Josh Poimboeuf]

On Wed, Sep 10, 2025 at 02:55:20PM +0800, Huacai Chen wrote:
> 
> On Wed, Sep 10, 2025 at 12:05 AM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> > On Tue, Sep 09, 2025 at 12:10:29PM +0800, Huacai Chen wrote:
> >
> > Then it can be __HEAD_RODATA, with the "w" removed:
> >
> > #define __HEAD_RODATA   .section        ".head.rodata","a"
> >
> > > From my point of view, the text section is still the best for HEAD.
> >
> > It belongs in a data section for two reasons:
> >
> >   1) It's an image header data structure.
> >
> >   2) We don't want objtool (or any other tooling) to try to validate it
> >      or otherwise treat it as text during the build.
> I'm sorry but I insist on my opinion. :)
> 
> Yes, there are reasons to put it into a data section, but there are
> also reasons to put it into a code section.
> 
> 1) ARM64, RISC-V and LoongArch have the same style (mix code and data
> in __HEAD), I don't want to do something special.

There's no need for anything special... Fo ARM64 and RISC-V, if their
head "code" is actually just structured data, that *also* belongs in a
data section.

And that can get changed if/when they get objtool support.  If not
before.

> 2) __HEAD is used for nearly all archs, except ARM64, RISC-V and
> LoongArch, other archs are almost pure code (so they must use a code
> section). However, the code in __HEAD is usually not like a regular
> function. In other word, if other archs add objtool support, __HEAD
> will also probably cause problems.

Hm?  Objtool can handle "non-regular" functions fine.  That's what the
unwind hints are for.  x86 has that already and it works fine.

What *actually* causes problems for objtool (and the whole point of this
discussion) is the placing of data in a text section.  I don't
understand why we're still arguing about whether that's the right thing
to do.  Not to mention the fact that using objtool as an excuse *not* to
do it seems completely backwards!

> 3) Many archs put __HEAD between __init_begin and __init_end, which
> means it is discarded at runtime, stack unwinder is useless for it.

Unwinding can easily (and often does) happen during boot, before init
memory is freed.

It could even happen in the head code, e.g. in a debugger.  (whether
that actually works might be a different story.)

But also, keep in mind that objtool has many other features beyond just
ORC generation.  In the future it would be quite foreseeable for some
other objtool feature to get confused by this "code" again and spit out
more warnings.

Similarly, if loongarch eventually switches to using sframe, and the
binutils assembler learns how to autogenerate sframe with minimal cfi
directives (a planned feature I believe), it would have the same problem
trying to decipher this "code".

> So, ignoring .head.text is not just a workaround for LoongArch, it is
> a proper solution for other archs.

I'm not convinced of that.  I don't think we want to ignore it on x86.

-- 
Josh

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

[Huacai Chen]

On Thu, Sep 11, 2025 at 11:23 AM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>
> On Wed, Sep 10, 2025 at 02:55:20PM +0800, Huacai Chen wrote:
> >
> > On Wed, Sep 10, 2025 at 12:05 AM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> > > On Tue, Sep 09, 2025 at 12:10:29PM +0800, Huacai Chen wrote:
> > >
> > > Then it can be __HEAD_RODATA, with the "w" removed:
> > >
> > > #define __HEAD_RODATA   .section        ".head.rodata","a"
> > >
> > > > From my point of view, the text section is still the best for HEAD.
> > >
> > > It belongs in a data section for two reasons:
> > >
> > >   1) It's an image header data structure.
> > >
> > >   2) We don't want objtool (or any other tooling) to try to validate it
> > >      or otherwise treat it as text during the build.
> > I'm sorry but I insist on my opinion. :)
> >
> > Yes, there are reasons to put it into a data section, but there are
> > also reasons to put it into a code section.
> >
> > 1) ARM64, RISC-V and LoongArch have the same style (mix code and data
> > in __HEAD), I don't want to do something special.
>
> There's no need for anything special... Fo ARM64 and RISC-V, if their
> head "code" is actually just structured data, that *also* belongs in a
> data section.
>
> And that can get changed if/when they get objtool support.  If not
> before.
>
> > 2) __HEAD is used for nearly all archs, except ARM64, RISC-V and
> > LoongArch, other archs are almost pure code (so they must use a code
> > section). However, the code in __HEAD is usually not like a regular
> > function. In other word, if other archs add objtool support, __HEAD
> > will also probably cause problems.
>
> Hm?  Objtool can handle "non-regular" functions fine.  That's what the
> unwind hints are for.  x86 has that already and it works fine.
>
> What *actually* causes problems for objtool (and the whole point of this
> discussion) is the placing of data in a text section.  I don't
> understand why we're still arguing about whether that's the right thing
> to do.  Not to mention the fact that using objtool as an excuse *not* to
> do it seems completely backwards!
>
> > 3) Many archs put __HEAD between __init_begin and __init_end, which
> > means it is discarded at runtime, stack unwinder is useless for it.
>
> Unwinding can easily (and often does) happen during boot, before init
> memory is freed.
>
> It could even happen in the head code, e.g. in a debugger.  (whether
> that actually works might be a different story.)
>
> But also, keep in mind that objtool has many other features beyond just
> ORC generation.  In the future it would be quite foreseeable for some
> other objtool feature to get confused by this "code" again and spit out
> more warnings.
>
> Similarly, if loongarch eventually switches to using sframe, and the
> binutils assembler learns how to autogenerate sframe with minimal cfi
> directives (a planned feature I believe), it would have the same problem
> trying to decipher this "code".
>
> > So, ignoring .head.text is not just a workaround for LoongArch, it is
> > a proper solution for other archs.
>
> I'm not convinced of that.  I don't think we want to ignore it on x86.
OK, then don't ignore .head.text in objtool. But I also don't want to
change .head.text to .head.data. So Tiezhu please just use unwind
hints (UNWIND_HINT_UNDEFINED) in __HEAD like the earliest version.
Thanks.


Huacai

>
> --
> Josh

[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 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 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 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 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 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
>