[Bug binutils/19549] New: ld.gold internal error on ARM with recursive linking

[arnd at arndb dot de]

https://sourceware.org/bugzilla/show_bug.cgi?id=19549

Bug ID: 19549
   Summary: ld.gold internal error on ARM with recursive linking
   Product: binutils
   Version: 2.27 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: arnd at arndb dot de
  Target Milestone: ---

Created attachment 8948
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8948&action=edit
shell script to provoke internal error in ld.gold

recursively linking multiple objects that together exceed 32MB of .text causes
an internal error with ld.gold:

CROSS=/home/arnd/cross-gcc/bin/arm-linux-gnueabi- bash test.sh
/home/arnd/cross-gcc/bin/arm-linux-gnueabi-ld.gold: internal error in
arm_branch_common, at /home/arnd/git/binutils/gold/arm.cc:4046

I created the test case to simulate a failure to link an 'allyesconfig' Linux
kernel, however the failure is slightly different. However, the failure case in
the kernel is different, there we get a relocation overflow because of missing
trampolines from the recursive linking.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/30033] binutils-2.40 broke arm-linux-gnueabi libraries on arm64 kernel with >4KB pages

[arnd at arndb dot de]

https://sourceware.org/bugzilla/show_bug.cgi?id=30033

Arnd Bergmann  changed:

   What|Removed |Added

 CC||hp at bitrange dot com,
   ||hp at sourceware dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug binutils/30033] New: binutils-2.40 broke arm-linux-gnueabi libraries on arm64 kernel with >4KB pages

[arnd at arndb dot de]

https://sourceware.org/bugzilla/show_bug.cgi?id=30033

Bug ID: 30033
   Summary: binutils-2.40 broke arm-linux-gnueabi libraries on
arm64 kernel with >4KB pages
   Product: binutils
   Version: 2.40
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: arnd at arndb dot de
  Target Milestone: ---

Running Debian Bookworm armhf user space on 64-bit kernels broke after the
update from binutils-2.39 to binutils-2.40. 

Booting a 32-bit root image using a 16KB or 64KB page kernel now fails as soon
as it loads a shared library that was built after the binutils update:
udevadm: error while loading shared libraries: libacl.so.1: ELF load command
address/offset not page-aligned
10:32 AM /sbin/init: error while loading shared libraries: libapparmor.so.1:
ELF load command address/offset not page-aligned

Reverting commit 1a26a53a0de ("ARM: Fix ld bloat introduced between
binutils-2.38 and 2.39") solves the problem again.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug binutils/30033] binutils-2.40 broke arm-linux-gnueabi libraries on arm64 kernel with >4KB pages

[arnd at arndb dot de]

https://sourceware.org/bugzilla/show_bug.cgi?id=30033

Arnd Bergmann  changed:

   What|Removed |Added

 Target||arm-linux-gnuabihf

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug binutils/30033] binutils-2.40 broke arm-linux-gnueabi libraries on arm64 kernel with >4KB pages

[arnd at arndb dot de]

https://sourceware.org/bugzilla/show_bug.cgi?id=30033

Arnd Bergmann  changed:

   What|Removed |Added

 Target|arm-linux-gnuabihf  |arm-linux-gnueabihf

--- Comment #3 from Arnd Bergmann  ---
The case I ran into was trying to create a bootable disk image for a Debian
armhf or armel system using the 'mmdebstrap' tool. The system does support
running 'compat' userspace on the CPU itself, so this uses the 'qemu-user-arm'
tool to run the installation process, but the problem is the same as when
running compat userspace.

mmdebstrap is useful for me to quickly test a 32-bit kernel image with a
working userspace, and it works fine on the other architectures supported by
Debian, as well as on stable Debian arm releases that were produced with
binutils versions 2.25 (which added support for 64KB page alignment) through
2.39.

My workstation is an Apple M1 based system that only works with 16KB pages, the
only other alternative I have would be to test on a much slower Chromebook, or
an cloud instance.

Regarding the kernel option, support for running 32-bit binaries with larger
pages was added experimentally at the same time as binutils support, but at the
time no distributions were built with new enough binutils yet so it was left
under CONFIG_EXPERT, see
https://lore.kernel.org/linux-arm-kernel/20141204182049.gb7...@arm.com/. Since
all distributions that are still supported now are built with binutils-2.25 or
higher, this is probably something that could be revisited, especially as more
users are going to want 16KB page support in their kernels, which has a better
tradeoff between performance and space overhead than using 64KB pages.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/22764] [2.30 Regression] ld fails to link 4.13 and 4.15 kernels on aarch64-linux-gnu

[arnd at arndb dot de]

https://sourceware.org/bugzilla/show_bug.cgi?id=22764

Arnd Bergmann  changed:

   What|Removed |Added

 CC||arnd at arndb dot de

--- Comment #11 from Arnd Bergmann  ---
I did some more testing with binutils-2.30 on arm64 randconfig kernels. One
major issue I came across was CONFIG_MODVERSIONS, which causes an error for
each exported symbol.

aarch64-linux-ld: init/main.o: relocation R_AARCH64_ABS32 against
`__crc_system_state' can not be used when making a shared object
aarch64-linux-ld: init/version.o: relocation R_AARCH64_ABS32 against
`__crc_init_uts_ns' can not be used when making a shared object
aarch64-linux-ld: init/do_mounts.o: relocation R_AARCH64_ABS32 against
`__crc_name_to_dev_t' can not be used when making a shared object
aarch64-linux-ld: init/init_task.o: relocation R_AARCH64_ABS32 against
`__crc_init_task' can not be used when making a shared object
aarch64-linux-ld: arch/arm64/kernel/fpsimd.o: relocation R_AARCH64_ABS32
against `__crc_kernel_neon_busy' can not be used when making a shared object
aarch64-linux-ld: arch/arm64/kernel/process.o: relocation R_AARCH64_ABS32
against `__crc___stack_chk_guard' can not be used when making a shared object
aarch64-linux-ld: arch/arm64/kernel/stacktrace.o: relocation R_AARCH64_ABS32
against `__crc_save_stack_trace_tsk' can not be used when making a shared
object


While changing one of the .S files, I also ran into a linker crash:

 aarch64-linux-ld: arch/arm64/kernel/head.o: relocation R_AARCH64_ABS32 against
`__rela_offset' can not be used when making a shared object
11:39 PM cross-gcc/bin/aarch64-linux-ld: BFD (GNU Binutils) 2.30 internal
error, aborting at /home/arnd/git/binutils/bfd/elfnn-aarch64.c:5279 in
elf64_aarch64_final_link_relocate
11:40 PM aarch64-linux-ld: Please report this bug.

This evidently was caused by the same two instructions that came up earlier:

   ldr w9, =__rela_offset  // offset to reloc table
   ldr w10, =__rela_size   // size of reloc table

After commenting these out, I got no further crashes.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/32584] New: ld.bfd slowdown linking some linux kernels

[arnd at arndb dot de]

https://sourceware.org/bugzilla/show_bug.cgi?id=32584

Bug ID: 32584
   Summary: ld.bfd slowdown linking some linux kernels
   Product: binutils
   Version: 2.39
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: arnd at arndb dot de
  Target Milestone: ---

I noticed a slowdown in link times between linux kernels 6.12 and 6.13,
bisected it to a commit that changed the section ordering, as well as
binutils-2.39 and higher, see my report on the kernel mailing list, see
https://lore.kernel.org/lkml/20250120212839.1675696-1-a...@kernel.org/.

Rong Xu further narrowed down the cause of the problem on the binutils side to
to commit fba1ac87dcb7 ("Fix the sorting algorithm for reloc entries").

I created a smaller test case for reproducing the issue, but it still exceeds
the 10MB limit for binutils bugzilla, so I uploaded the file to
https://drive.google.com/file/d/1M_ccr8RINzfjpU1qA5qA0rhRIGgDOFix/view?usp=sharing

time x86_64-linux-gnu-ld  -m elf_x86_64 -z noexecstack  --emit-relocs
--discard-none -z max-page-size=0x20 --gc-sections --build-id=sha1
--orphan-handling=warn --script=./arch/x86/kernel/vmlinux.lds --strip-debug -o
.tmp_vmlinux1 --whole-archive vmlinux.a init/version-timestamp.o
--no-whole-archive --start-group lib/lib.a arch/x86/lib/lib.a --end-group
.tmp_vmlinux0.kallsyms.o
real0m31.128s
user0m30.472s
sys 0m0.277s

time x86_64-linux-ld-2.36  -m elf_x86_64 -z noexecstack  --emit-relocs
--discard-none -z max-page-size=0x20 --gc-sections --build-id=sha1
--orphan-handling=warn --script=./arch/x86/kernel/vmlinux.lds --strip-debug -o
.tmp_vmlinux1 --whole-archive vmlinux.a init/version-timestamp.o
--no-whole-archive --start-group lib/lib.a arch/x86/lib/lib.a --end-group
.tmp_vmlinux0.kallsyms.o 
real0m1.142s
user0m0.898s
sys 0m0.237s

-- 
You are receiving this mail because:
You are on the CC list for the bug.