[build fail] v6.11-rc2 from "ARM: 9404/1: arm32: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION"

[build fail] v6.11-rc2 from "ARM: 9404/1: arm32: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION"

[Harith George]

Hi,

I am seeing a regression in "make xipImage" builds in mainline tree 
v6.11-rc2  with LD segmentation fault.

$ make V=1 xipImage
...
+ arm-poky-linux-musleabi-ld -EL -z noexecstack --no-undefined -X 
--pic-veneer -z norelro --build-id=sha1 --orphan-handling=warn 
--script=./arch/arm/kernel/vmlinux.lds -o vmlinux --whole-archive 
vmlinux.a init/version-timestamp.o --no-whole-archive --start-group 
arch/arm/lib/lib.a lib/lib.a --end-group
scripts/link-vmlinux.sh: line 49: 3371164 Segmentation fault      (core 
dumped) ${ld} ${ldflags} -o ${output} ${wl}--whole-archive ${objs} 
${wl}--no-whole-archive ${wl}--start-group ${libs} ${wl}--end-group 
${kallsymso} ${btf_vmlinux_bin_o} ${ldlibs}
make[2]: *** [scripts/Makefile.vmlinux:34: vmlinux] Error 139
make[2]: *** Deleting file 'vmlinux'
make[1]: *** [/home/amol/hgg/mainline/linux/Makefile:1156: vmlinux] Error 2
make: *** [Makefile:224: __sub-make] Error 2

git bisect pointed to ed0f941022515ff40473("ARM: 9404/1: arm32: enable 
HAVE_LD_DEAD_CODE_DATA_ELIMINATION")

"CONFIG_HAVE_LD_DEAD_CODE_DATA_ELIMINATION=y" is getting set with the 
commit in my .config.
But, my .config is _not_ enabling the "LD_DEAD_CODE_DATA_ELIMINATION" flag.

Reverting commit ed0f94102251, resolves the linking fail.
Infact, reverting just the ".reloc  .text, R_ARM_NONE, ." additions in 
arch/arm/kernel/entry-armv.S resolves the linking fail.

My toolchain is
arm-poky-linux-musleabi-gcc (GCC) 9.2.0
GNU ld (GNU Binutils) 2.32.0.20190204

I am working on a new platform. Hence my .config/code has other platform 
related additions which would not make sense on current mainline, which 
is why I have not added it here. Do let me know if you would still like 
to have the .config file.


Thanks,
Warm Regards,
Harith

Re: [build fail] v6.11-rc2 from "ARM: 9404/1: arm32: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION"

[liuyuntao (F)]

OK，I am currently troubleshooting this issue.

On 2024/8/7 13:12, Harith George wrote:
> Hi,
> 
> I am seeing a regression in "make xipImage" builds in mainline tree 
> v6.11-rc2  with LD segmentation fault.
> 
> $ make V=1 xipImage
> ...
> + arm-poky-linux-musleabi-ld -EL -z noexecstack --no-undefined -X 
> --pic-veneer -z norelro --build-id=sha1 --orphan-handling=warn 
> --script=./arch/arm/kernel/vmlinux.lds -o vmlinux --whole-archive 
> vmlinux.a init/version-timestamp.o --no-whole-archive --start-group 
> arch/arm/lib/lib.a lib/lib.a --end-group
> scripts/link-vmlinux.sh: line 49: 3371164 Segmentation fault      (core 
> dumped) ${ld} ${ldflags} -o ${output} ${wl}--whole-archive ${objs} 
> ${wl}--no-whole-archive ${wl}--start-group ${libs} ${wl}--end-group 
> ${kallsymso} ${btf_vmlinux_bin_o} ${ldlibs}
> make[2]: *** [scripts/Makefile.vmlinux:34: vmlinux] Error 139
> make[2]: *** Deleting file 'vmlinux'
> make[1]: *** [/home/amol/hgg/mainline/linux/Makefile:1156: vmlinux] Error 2
> make: *** [Makefile:224: __sub-make] Error 2
> 
> git bisect pointed to ed0f941022515ff40473("ARM: 9404/1: arm32: enable 
> HAVE_LD_DEAD_CODE_DATA_ELIMINATION")
> 
> "CONFIG_HAVE_LD_DEAD_CODE_DATA_ELIMINATION=y" is getting set with the 
> commit in my .config.
> But, my .config is _not_ enabling the "LD_DEAD_CODE_DATA_ELIMINATION" flag.
> 
> Reverting commit ed0f94102251, resolves the linking fail.
> Infact, reverting just the ".reloc  .text, R_ARM_NONE, ." additions in 
> arch/arm/kernel/entry-armv.S resolves the linking fail.
> 
> My toolchain is
> arm-poky-linux-musleabi-gcc (GCC) 9.2.0
> GNU ld (GNU Binutils) 2.32.0.20190204
> 
> I am working on a new platform. Hence my .config/code has other platform 
> related additions which would not make sense on current mainline, which 
> is why I have not added it here. Do let me know if you would still like 
> to have the .config file.
> 
> 
> Thanks,
> Warm Regards,
> Harith
> 
> 
> 

Re: [build fail] v6.11-rc2 from "ARM: 9404/1: arm32: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION"

[liuyuntao (F)]

It seems to be ok with vexpress_defconfig in mainline tree v6.11-rc2,
I may need your .config/code file for further testing.

On 2024/8/7 13:12, Harith George wrote:
> Hi,
> 
> I am seeing a regression in "make xipImage" builds in mainline tree 
> v6.11-rc2  with LD segmentation fault.
> 
> $ make V=1 xipImage
> ...
> + arm-poky-linux-musleabi-ld -EL -z noexecstack --no-undefined -X 
> --pic-veneer -z norelro --build-id=sha1 --orphan-handling=warn 
> --script=./arch/arm/kernel/vmlinux.lds -o vmlinux --whole-archive 
> vmlinux.a init/version-timestamp.o --no-whole-archive --start-group 
> arch/arm/lib/lib.a lib/lib.a --end-group
> scripts/link-vmlinux.sh: line 49: 3371164 Segmentation fault      (core 
> dumped) ${ld} ${ldflags} -o ${output} ${wl}--whole-archive ${objs} 
> ${wl}--no-whole-archive ${wl}--start-group ${libs} ${wl}--end-group 
> ${kallsymso} ${btf_vmlinux_bin_o} ${ldlibs}
> make[2]: *** [scripts/Makefile.vmlinux:34: vmlinux] Error 139
> make[2]: *** Deleting file 'vmlinux'
> make[1]: *** [/home/amol/hgg/mainline/linux/Makefile:1156: vmlinux] Error 2
> make: *** [Makefile:224: __sub-make] Error 2
> 
> git bisect pointed to ed0f941022515ff40473("ARM: 9404/1: arm32: enable 
> HAVE_LD_DEAD_CODE_DATA_ELIMINATION")
> 
> "CONFIG_HAVE_LD_DEAD_CODE_DATA_ELIMINATION=y" is getting set with the 
> commit in my .config.
> But, my .config is _not_ enabling the "LD_DEAD_CODE_DATA_ELIMINATION" flag.
> 
> Reverting commit ed0f94102251, resolves the linking fail.
> Infact, reverting just the ".reloc  .text, R_ARM_NONE, ." additions in 
> arch/arm/kernel/entry-armv.S resolves the linking fail.
> 
> My toolchain is
> arm-poky-linux-musleabi-gcc (GCC) 9.2.0
> GNU ld (GNU Binutils) 2.32.0.20190204
> 
> I am working on a new platform. Hence my .config/code has other platform 
> related additions which would not make sense on current mainline, which 
> is why I have not added it here. Do let me know if you would still like 
> to have the .config file.
> 
> 
> Thanks,
> Warm Regards,
> Harith
> 
> 
> 

Re: [build fail] v6.11-rc2 from "ARM: 9404/1: arm32: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION"

[Harith George]

[-- Attachment #1: Type: text/plain, Size: 319 bytes --]



On 07-08-2024 15:19, liuyuntao (F) wrote:
> It seems to be ok with vexpress_defconfig in mainline tree v6.11-rc2,
> I may need your .config/code file for further testing.
> 
Please find attached minimal patches just for your testing. "make 
ARCH=arm e7_defconfig; make ARCH=arm xipImage"

Thanks,
Warm Regards,
Harith

[-- Attachment #2: ldissue.tar.gz --]
[-- Type: application/x-gzip, Size: 5741 bytes --]

Re: [build fail] v6.11-rc2 from "ARM: 9404/1: arm32: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION"

[liuyuntao (F)]

Thanks, I reproduce the link error with toolchain
gcc version 9.3.0
GNU ld (GNU Binutils) 2.33.1

with same gcc version, just upgrading ld version to 2.36.1, it does not 
segfault and build completes. there should be bugs in low version of ld,
and the ".reloc  .text, R_ARM_NONE, ." triggers that.


On 2024/8/7 19:51, Harith George wrote:
> 
> 
> On 07-08-2024 15:19, liuyuntao (F) wrote:
>> It seems to be ok with vexpress_defconfig in mainline tree v6.11-rc2,
>> I may need your .config/code file for further testing.
>>
> Please find attached minimal patches just for your testing. "make 
> ARCH=arm e7_defconfig; make ARCH=arm xipImage"
> 
> Thanks,
> Warm Regards,
> Harith

Re: [build fail] v6.11-rc2 from "ARM: 9404/1: arm32: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION"

[Harith George]

On 07-08-2024 20:52, liuyuntao (F) wrote:
> Thanks, I reproduce the link error with toolchain
> gcc version 9.3.0
> GNU ld (GNU Binutils) 2.33.1
> 
> with same gcc version, just upgrading ld version to 2.36.1, it does not 
> segfault and build completes. there should be bugs in low version of ld,
> and the ".reloc  .text, R_ARM_NONE, ." triggers that.
> 
Thanks for confirming.

I guess we need to add something like
#if !CONFIG_CC_IS_GCC || CONFIG_LD_VERSION >= 23600
around the entry-armv.S changes and maybe select 
HAVE_LD_DEAD_CODE_DATA_ELIMINATION in arch/arm/Kconfig only if the same 
conditions are met ??

I had screwed up the CC list when I last replied and LAK list got 
changed to lak-join email id by mistake. Fixing that in this reply as well.

Thanks,
Warm Regards,
Harith

Re: [build fail] v6.11-rc2 from "ARM: 9404/1: arm32: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION"

[Arnd Bergmann]

On Wed, Aug 7, 2024, at 17:36, Harith George wrote:
> On 07-08-2024 20:52, liuyuntao (F) wrote:
>> Thanks, I reproduce the link error with toolchain
>> gcc version 9.3.0
>> GNU ld (GNU Binutils) 2.33.1
>> 
>> with same gcc version, just upgrading ld version to 2.36.1, it does not 
>> segfault and build completes. there should be bugs in low version of ld,
>> and the ".reloc  .text, R_ARM_NONE, ." triggers that.
>> 
> Thanks for confirming.
>
> I guess we need to add something like
> #if !CONFIG_CC_IS_GCC || CONFIG_LD_VERSION >= 23600
> around the entry-armv.S changes and maybe select 
> HAVE_LD_DEAD_CODE_DATA_ELIMINATION in arch/arm/Kconfig only if the same 
> conditions are met ??

I think it makes most sense to have a minimum LD
version as a dependency for HAVE_LD_DEAD_CODE_DATA_ELIMINATION.
Are you sure that 2.36 is the first one that works, and it's
not just 2.33 specifically that is broken?

If so, we could use

--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -117,7 +117,7 @@ config ARM
        select HAVE_KERNEL_XZ
        select HAVE_KPROBES if !XIP_KERNEL && !CPU_ENDIAN_BE32 && !CPU_V7M && !CPU_32v3
        select HAVE_KRETPROBES if HAVE_KPROBES
-       select HAVE_LD_DEAD_CODE_DATA_ELIMINATION
+       select HAVE_LD_DEAD_CODE_DATA_ELIMINATION if (LD_VERSION >= 23600 || LD_IS_LLD)
        select HAVE_MOD_ARCH_SPECIFIC
        select HAVE_NMI
        select HAVE_OPTPROBES if !THUMB2_KERNEL


binutils only takes a few seconds to build from source, so
you could just try all version from 2.25 (the oldest supported)
to 2.36) to see which ones work.

       Arnd

Re: [build fail] v6.11-rc2 from "ARM: 9404/1: arm32: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION"

[liuyuntao (F)]

OK, i will test these version soon.

On 2024/8/7 23:41, Arnd Bergmann wrote:
> On Wed, Aug 7, 2024, at 17:36, Harith George wrote:
>> On 07-08-2024 20:52, liuyuntao (F) wrote:
>>> Thanks, I reproduce the link error with toolchain
>>> gcc version 9.3.0
>>> GNU ld (GNU Binutils) 2.33.1
>>>
>>> with same gcc version, just upgrading ld version to 2.36.1, it does not
>>> segfault and build completes. there should be bugs in low version of ld,
>>> and the ".reloc  .text, R_ARM_NONE, ." triggers that.
>>>
>> Thanks for confirming.
>>
>> I guess we need to add something like
>> #if !CONFIG_CC_IS_GCC || CONFIG_LD_VERSION >= 23600
>> around the entry-armv.S changes and maybe select
>> HAVE_LD_DEAD_CODE_DATA_ELIMINATION in arch/arm/Kconfig only if the same
>> conditions are met ??
> 
> I think it makes most sense to have a minimum LD
> version as a dependency for HAVE_LD_DEAD_CODE_DATA_ELIMINATION.
> Are you sure that 2.36 is the first one that works, and it's
> not just 2.33 specifically that is broken?
> 
> If so, we could use
> 
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -117,7 +117,7 @@ config ARM
>          select HAVE_KERNEL_XZ
>          select HAVE_KPROBES if !XIP_KERNEL && !CPU_ENDIAN_BE32 && !CPU_V7M && !CPU_32v3
>          select HAVE_KRETPROBES if HAVE_KPROBES
> -       select HAVE_LD_DEAD_CODE_DATA_ELIMINATION
> +       select HAVE_LD_DEAD_CODE_DATA_ELIMINATION if (LD_VERSION >= 23600 || LD_IS_LLD)
>          select HAVE_MOD_ARCH_SPECIFIC
>          select HAVE_NMI
>          select HAVE_OPTPROBES if !THUMB2_KERNEL
> 
> 
> binutils only takes a few seconds to build from source, so
> you could just try all version from 2.25 (the oldest supported)
> to 2.36) to see which ones work.
> 
>         Arnd

Re: [build fail] v6.11-rc2 from "ARM: 9404/1: arm32: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION"

[Harith George]

On 07-08-2024 21:11, Arnd Bergmann wrote:
> On Wed, Aug 7, 2024, at 17:36, Harith George wrote:
>> On 07-08-2024 20:52, liuyuntao (F) wrote:
>>> Thanks, I reproduce the link error with toolchain
>>> gcc version 9.3.0
>>> GNU ld (GNU Binutils) 2.33.1
>>>
>>> with same gcc version, just upgrading ld version to 2.36.1, it does not
>>> segfault and build completes. there should be bugs in low version of ld,
>>> and the ".reloc  .text, R_ARM_NONE, ." triggers that.
>>>
>> Thanks for confirming.
>>
>> I guess we need to add something like
>> #if !CONFIG_CC_IS_GCC || CONFIG_LD_VERSION >= 23600
>> around the entry-armv.S changes and maybe select
>> HAVE_LD_DEAD_CODE_DATA_ELIMINATION in arch/arm/Kconfig only if the same
>> conditions are met ??
> 
> I think it makes most sense to have a minimum LD
> version as a dependency for HAVE_LD_DEAD_CODE_DATA_ELIMINATION.
> Are you sure that 2.36 is the first one that works, and it's
> not just 2.33 specifically that is broken?
> 
> If so, we could use
> 
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -117,7 +117,7 @@ config ARM
>          select HAVE_KERNEL_XZ
>          select HAVE_KPROBES if !XIP_KERNEL && !CPU_ENDIAN_BE32 && !CPU_V7M && !CPU_32v3
>          select HAVE_KRETPROBES if HAVE_KPROBES
> -       select HAVE_LD_DEAD_CODE_DATA_ELIMINATION
> +       select HAVE_LD_DEAD_CODE_DATA_ELIMINATION if (LD_VERSION >= 23600 || LD_IS_LLD)
>          select HAVE_MOD_ARCH_SPECIFIC
>          select HAVE_NMI
>          select HAVE_OPTPROBES if !THUMB2_KERNEL
>
The select alone may not be enough. Wont the changes in 
arch/arm/kernel/entry-armv.S still result in LD Segfaults even if the 
HAVE_LD_DEAD_CODE_DATA_ELIMINATION flag is not set in .config for older 
toolchains?

Thanks,
Warm Regards,
Harith
> 
> binutils only takes a few seconds to build from source, so
> you could just try all version from 2.25 (the oldest supported)
> to 2.36) to see which ones work.
> 
>         Arnd

Re: [build fail] v6.11-rc2 from "ARM: 9404/1: arm32: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION"

[liuyuntao (F)]

On 2024/8/7 23:48, Harith George wrote:
> 
> 
> On 07-08-2024 21:11, Arnd Bergmann wrote:
>> On Wed, Aug 7, 2024, at 17:36, Harith George wrote:
>>> On 07-08-2024 20:52, liuyuntao (F) wrote:
>>>> Thanks, I reproduce the link error with toolchain
>>>> gcc version 9.3.0
>>>> GNU ld (GNU Binutils) 2.33.1
>>>>
>>>> with same gcc version, just upgrading ld version to 2.36.1, it does not
>>>> segfault and build completes. there should be bugs in low version of 
>>>> ld,
>>>> and the ".reloc  .text, R_ARM_NONE, ." triggers that.
>>>>
>>> Thanks for confirming.
>>>
>>> I guess we need to add something like
>>> #if !CONFIG_CC_IS_GCC || CONFIG_LD_VERSION >= 23600
>>> around the entry-armv.S changes and maybe select
>>> HAVE_LD_DEAD_CODE_DATA_ELIMINATION in arch/arm/Kconfig only if the same
>>> conditions are met ??
>>
>> I think it makes most sense to have a minimum LD
>> version as a dependency for HAVE_LD_DEAD_CODE_DATA_ELIMINATION.
>> Are you sure that 2.36 is the first one that works, and it's
>> not just 2.33 specifically that is broken?
>>
>> If so, we could use
>>
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -117,7 +117,7 @@ config ARM
>>          select HAVE_KERNEL_XZ
>>          select HAVE_KPROBES if !XIP_KERNEL && !CPU_ENDIAN_BE32 && 
>> !CPU_V7M && !CPU_32v3
>>          select HAVE_KRETPROBES if HAVE_KPROBES
>> -       select HAVE_LD_DEAD_CODE_DATA_ELIMINATION
>> +       select HAVE_LD_DEAD_CODE_DATA_ELIMINATION if (LD_VERSION >= 
>> 23600 || LD_IS_LLD)
>>          select HAVE_MOD_ARCH_SPECIFIC
>>          select HAVE_NMI
>>          select HAVE_OPTPROBES if !THUMB2_KERNEL
>>
> The select alone may not be enough. Wont the changes in 
> arch/arm/kernel/entry-armv.S still result in LD Segfaults even if the 
> HAVE_LD_DEAD_CODE_DATA_ELIMINATION flag is not set in .config for older 
> toolchains?
> 

Yes, that is it.
apply this patch, it should sovle the build issue with older version GUN ld.

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 54b2bb817a7f..173159e93c99 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -117,7 +117,7 @@ config ARM
  	select HAVE_KERNEL_XZ
  	select HAVE_KPROBES if !XIP_KERNEL && !CPU_ENDIAN_BE32 && !CPU_V7M
  	select HAVE_KRETPROBES if HAVE_KPROBES
-	select HAVE_LD_DEAD_CODE_DATA_ELIMINATION
+	select HAVE_LD_DEAD_CODE_DATA_ELIMINATION if (LD_VERSION >= 23600 || 
LD_IS_LLD)
  	select HAVE_MOD_ARCH_SPECIFIC
  	select HAVE_NMI
  	select HAVE_OPTPROBES if !THUMB2_KERNEL
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index f01d23a220e6..cd443faf8645 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -29,6 +29,12 @@
  #include "entry-header.S"
  #include <asm/probes.h>

+#ifdef CONFIG_HAVE_LD_DEAD_CODE_DATA_ELIMINATION
+#define RELOC_TEXT_NONE (.reloc  .text, R_ARM_NONE, .)
+#else
+#define RELOC_TEXT_NONE
+#endif
+
  /*
   * Interrupt handling.
   */
@@ -1065,7 +1071,7 @@ vector_addrexcptn:
  	.globl	vector_fiq

  	.section .vectors, "ax", %progbits
-	.reloc  .text, R_ARM_NONE, .
+	RELOC_TEXT_NONE
  	W(b)	vector_rst
  	W(b)	vector_und
  ARM(	.reloc	., R_ARM_LDR_PC_G0, .L__vector_swi		)
@@ -1079,7 +1085,7 @@ THUMB(	.reloc	., R_ARM_THM_PC12, .L__vector_swi		)

  #ifdef CONFIG_HARDEN_BRANCH_HISTORY
  	.section .vectors.bhb.loop8, "ax", %progbits
-	.reloc  .text, R_ARM_NONE, .
+	RELOC_TEXT_NONE
  	W(b)	vector_rst
  	W(b)	vector_bhb_loop8_und
  ARM(	.reloc	., R_ARM_LDR_PC_G0, .L__vector_bhb_loop8_swi	)
@@ -1092,7 +1098,7 @@ THUMB(	.reloc	., R_ARM_THM_PC12, 
.L__vector_bhb_loop8_swi	)
  	W(b)	vector_bhb_loop8_fiq

  	.section .vectors.bhb.bpiall, "ax", %progbits
-	.reloc  .text, R_ARM_NONE, .
+	RELOC_TEXT_NONE
  	W(b)	vector_rst
  	W(b)	vector_bhb_bpiall_und
  ARM(	.reloc	., R_ARM_LDR_PC_G0, .L__vector_bhb_bpiall_swi	)

> Thanks,
> Warm Regards,
> Harith
>>
>> binutils only takes a few seconds to build from source, so
>> you could just try all version from 2.25 (the oldest supported)
>> to 2.36) to see which ones work.
>>
>>         Arnd
> 

Re: [build fail] v6.11-rc2 from "ARM: 9404/1: arm32: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION"

[liuyuntao (F)]

On 2024/8/7 23:41, Arnd Bergmann wrote:
> On Wed, Aug 7, 2024, at 17:36, Harith George wrote:
>> On 07-08-2024 20:52, liuyuntao (F) wrote:
>>> Thanks, I reproduce the link error with toolchain
>>> gcc version 9.3.0
>>> GNU ld (GNU Binutils) 2.33.1
>>>
>>> with same gcc version, just upgrading ld version to 2.36.1, it does not
>>> segfault and build completes. there should be bugs in low version of ld,
>>> and the ".reloc  .text, R_ARM_NONE, ." triggers that.
>>>
>> Thanks for confirming.
>>
>> I guess we need to add something like
>> #if !CONFIG_CC_IS_GCC || CONFIG_LD_VERSION >= 23600
>> around the entry-armv.S changes and maybe select
>> HAVE_LD_DEAD_CODE_DATA_ELIMINATION in arch/arm/Kconfig only if the same
>> conditions are met ??
> 
> I think it makes most sense to have a minimum LD
> version as a dependency for HAVE_LD_DEAD_CODE_DATA_ELIMINATION.
> Are you sure that 2.36 is the first one that works, and it's
> not just 2.33 specifically that is broken?
> 
> If so, we could use
> 
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -117,7 +117,7 @@ config ARM
>          select HAVE_KERNEL_XZ
>          select HAVE_KPROBES if !XIP_KERNEL && !CPU_ENDIAN_BE32 && !CPU_V7M && !CPU_32v3
>          select HAVE_KRETPROBES if HAVE_KPROBES
> -       select HAVE_LD_DEAD_CODE_DATA_ELIMINATION
> +       select HAVE_LD_DEAD_CODE_DATA_ELIMINATION if (LD_VERSION >= 23600 || LD_IS_LLD)
>          select HAVE_MOD_ARCH_SPECIFIC
>          select HAVE_NMI
>          select HAVE_OPTPROBES if !THUMB2_KERNEL
> 
> 
> binutils only takes a few seconds to build from source, so
> you could just try all version from 2.25 (the oldest supported)
> to 2.36) to see which ones work.

After testing, all version of ld with version earlier than 2.36 has a 
build issue.

as Harith mentioned:
> The select alone may not be enough. Wont the changes in arch/arm/kernel/entry-armv.S still result in LD Segfaults even if the HAVE_LD_DEAD_CODE_DATA_ELIMINATION flag is not set in .config for older toolchains? 

I think we could eliminate the impact of ".reloc  .text, R_ARM_NONE, ." 
when CONFIG_LD_DEAD_CODE_DATA_ELIMINATION is not enabled.

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 54b2bb817a7f..173159e93c99 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -117,7 +117,7 @@ config ARM
         select HAVE_KERNEL_XZ
         select HAVE_KPROBES if !XIP_KERNEL && !CPU_ENDIAN_BE32 && !CPU_V7M
         select HAVE_KRETPROBES if HAVE_KPROBES
-       select HAVE_LD_DEAD_CODE_DATA_ELIMINATION
+       select HAVE_LD_DEAD_CODE_DATA_ELIMINATION if (LD_VERSION >= 
23600 || LD_IS_LLD)
         select HAVE_MOD_ARCH_SPECIFIC
         select HAVE_NMI
         select HAVE_OPTPROBES if !THUMB2_KERNEL
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index f01d23a220e6..cd443faf8645 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -29,6 +29,12 @@
  #include "entry-header.S"
  #include <asm/probes.h>

+#ifdef CONFIG_HAVE_LD_DEAD_CODE_DATA_ELIMINATION
+#define RELOC_TEXT_NONE (.reloc  .text, R_ARM_NONE, .)
+#else
+#define RELOC_TEXT_NONE
+#endif
+
  /*
   * Interrupt handling.
   */
@@ -1065,7 +1071,7 @@ vector_addrexcptn:
         .globl  vector_fiq

         .section .vectors, "ax", %progbits
-       .reloc  .text, R_ARM_NONE, .
+       RELOC_TEXT_NONE
         W(b)    vector_rst
         W(b)    vector_und
  ARM(   .reloc  ., R_ARM_LDR_PC_G0, .L__vector_swi              )
@@ -1079,7 +1085,7 @@ THUMB(    .reloc  ., R_ARM_THM_PC12, 
.L__vector_swi               )

  #ifdef CONFIG_HARDEN_BRANCH_HISTORY
         .section .vectors.bhb.loop8, "ax", %progbits
-       .reloc  .text, R_ARM_NONE, .
+       RELOC_TEXT_NONE
         W(b)    vector_rst
         W(b)    vector_bhb_loop8_und
  ARM(   .reloc  ., R_ARM_LDR_PC_G0, .L__vector_bhb_loop8_swi    )
@@ -1092,7 +1098,7 @@ THUMB(    .reloc  ., R_ARM_THM_PC12, 
.L__vector_bhb_loop8_swi     )
         W(b)    vector_bhb_loop8_fiq

         .section .vectors.bhb.bpiall, "ax", %progbits
-       .reloc  .text, R_ARM_NONE, .
+       RELOC_TEXT_NONE
         W(b)    vector_rst
         W(b)    vector_bhb_bpiall_und
  ARM(   .reloc  ., R_ARM_LDR_PC_G0, .L__vector_bhb_bpiall_swi   )

Re: [build fail] v6.11-rc2 from "ARM: 9404/1: arm32: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION"

[Arnd Bergmann]

On Wed, Aug 7, 2024, at 07:12, Harith George wrote:
> Hi,
>
> I am seeing a regression in "make xipImage" builds in mainline tree 
> v6.11-rc2  with LD segmentation fault.
>
> $ make V=1 xipImage
> ...
> + arm-poky-linux-musleabi-ld -EL -z noexecstack --no-undefined -X 
> --pic-veneer -z norelro --build-id=sha1 --orphan-handling=warn 
> --script=./arch/arm/kernel/vmlinux.lds -o vmlinux --whole-archive 
> vmlinux.a init/version-timestamp.o --no-whole-archive --start-group 
> arch/arm/lib/lib.a lib/lib.a --end-group
> scripts/link-vmlinux.sh: line 49: 3371164 Segmentation fault      (core 
> dumped) ${ld} ${ldflags} -o ${output} ${wl}--whole-archive ${objs} 
> ${wl}--no-whole-archive ${wl}--start-group ${libs} ${wl}--end-group 
> ${kallsymso} ${btf_vmlinux_bin_o} ${ldlibs}
> make[2]: *** [scripts/Makefile.vmlinux:34: vmlinux] Error 139
> make[2]: *** Deleting file 'vmlinux'
> make[1]: *** [/home/amol/hgg/mainline/linux/Makefile:1156: vmlinux] Error 2
> make: *** [Makefile:224: __sub-make] Error 2
>
> git bisect pointed to ed0f941022515ff40473("ARM: 9404/1: arm32: enable 
> HAVE_LD_DEAD_CODE_DATA_ELIMINATION")
>
> "CONFIG_HAVE_LD_DEAD_CODE_DATA_ELIMINATION=y" is getting set with the 
> commit in my .config.
> But, my .config is _not_ enabling the "LD_DEAD_CODE_DATA_ELIMINATION" flag.
>
> Reverting commit ed0f94102251, resolves the linking fail.
> Infact, reverting just the ".reloc  .text, R_ARM_NONE, ." additions in 
> arch/arm/kernel/entry-armv.S resolves the linking fail.
>
> My toolchain is
> arm-poky-linux-musleabi-gcc (GCC) 9.2.0
> GNU ld (GNU Binutils) 2.32.0.20190204

Obviously 'ld' should not segfault, so there is at least one bug
there, possibly also a kernel bug that triggered this. Can you
try with newer binutils? This should hopefully either solve your
problem or produce a more useful error message if there is still a
kernel problem.

Any of the binary toolchains below should work in general,
the latest one is the gcc-14.2/binutils-2.43 version I uploaded
to kernel.org the other day.

https://mirrors.edge.kernel.org/pub/tools/crosstool/index.html
https://toolchains.bootlin.com/releases_armv7-eabihf.html
https://musl.cc/

     Arnd

Re: [build fail] v6.11-rc2 from "ARM: 9404/1: arm32: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION"

[Harith George]

On 07-08-2024 15:40, Arnd Bergmann wrote:
> Obviously 'ld' should not segfault, so there is at least one bug
> there, possibly also a kernel bug that triggered this. Can you
> try with newer binutils? This should hopefully either solve your
> problem or produce a more useful error message if there is still a
> kernel problem.
> 
> Any of the binary toolchains below should work in general,
> the latest one is the gcc-14.2/binutils-2.43 version I uploaded
> to kernel.org the other day.

So, I tested with 3 more gcc builds.

gcc14.2 (x86_64-gcc-14.2.0-nolibc-arm-linux-gnueabi.tar.xz) and gcc9.5 
(x86_64-gcc-9.5.0-nolibc-arm-linux-gnueabi.tar.xz) from 
https://mirrors.edge.kernel.org/pub/tools/crosstool/index.html
works and in both these ld does not segfault and build completes.

But gcc9.3 (armv7-eabihf--musl--stable-2020.08-1.tar.bz2) from 
(https://toolchains.bootlin.com/releases_armv7-eabihf.html) resulted in 
the same LD segfault below.

+ arm-buildroot-linux-musleabihf-ld -EL -z noexecstack --no-undefined -X 
--pic-veneer -z norelro --build-id=sha1 --orphan-handling=warn 
--script=./arch/arm/kernel/vmlinux.lds --strip-debug -o .tmp_vmlinux1 
--whole-archive vmlinux.a init/version-timestamp.o --no-whole-archive 
--start-group arch/arm/lib/lib.a lib/lib.a --end-group 
.tmp_vmlinux0.kallsyms.o
scripts/link-vmlinux.sh: line 49: 3802905 Segmentation fault      ${ld} 
${ldflags} -o ${output} ${wl}--whole-archive ${objs} 
${wl}--no-whole-archive ${wl}--start-group ${libs} ${wl}--end-group 
${kallsymso} ${btf_vmlinux_bin_o} ${ldlibs}
make[2]: *** [scripts/Makefile.vmlinux:34: vmlinux] Error 139
make[1]: *** [/home/amol/hgg/mainline/linux/Makefile:1156: vmlinux] Error 2


Thanks,
Warm Regards,
Harith