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.0On 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?
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
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
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
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 >
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
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
>
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
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
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
>
>
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
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
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
>
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
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 >
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
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
© 2016 - 2025 Red Hat, Inc.