On ARM, if the compiled size of the .text section exceeds 32MB (the maximum call displacement), the linker will not necessarily be able to resolve relocations for the calls. The below asm file illustrates the problem (it is also possible to reproduce in IR, but the reproduction is too large for here.)
$ cat call-range-l.s
$ ~/src/llvm-build-rel/bin/llvm-mc -filetype=obj -o call-range-l.o call-range-l.s -triple armv7
$ ~/src/binutils-gdb-inst-arm/bin/ld.bfd -m armelf_linux_eabi -e foo call-range-l.o
call-range-l.o: In function foo': (.text+0x5f5e100): relocation truncated to fit: R_ARM_CALL against symbol bar' defined in .text._Z1fv[_Z1fv] section in call-range-l.o
$ ~/src/binutils-gdb-inst-arm/bin/ld.gold -m armelf_linux_eabi -e foo call-range-l.o
.../src/binutils-gdb-inst-arm/bin/ld.gold: internal error in arm_branch_common, at ../../binutils-gdb/gold/arm.cc:4014
This problem particularly comes up when using LTO.
An easy way to solve the problem would be to teach the LTO backend to use -function-sections on architectures where this matters (e.g. ARM), if we're comfortable with the assumption that only LTO can create objects with .text sections that large. It may also be possible for the backend to do something smarter based on the computed size of .text.
The text was updated successfully, but these errors were encountered:
Some concerns where raised about enabling -ffunction-sections by default as this could increase binary size and link time. I had a look and could not find a way to determine/guess the file size of the resulting, as the sections to place functions in is determined while emitting functions, so before the total size is known.
Some concerns where raised about enabling -ffunction-sections by default as
this could increase binary size and link time. I had a look and could not
find a way to determine/guess the file size of the resulting, as the
sections to place functions in is determined while emitting functions, so
before the total size is known.
FWIW, lld + LTO now has function-sections/data-sections by default.
I plan to do a similar change for the gold plugin and COFF in the next bit.
I was under the impression that > 32MB text was simply not allowed on ARM and multiple text sections or shared libraries should be used to work around this. -ffunction-sections could help with size reduction but the root issue of support is still there. I believe iOS has this restriction as well.