Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

We can emit unlinkable object files when compiling large modules on (at least) ARM #23373

Closed
pcc opened this issue Mar 23, 2015 · 11 comments
Closed
Labels
backend:ARM bugzilla

Comments

@pcc
Copy link
Contributor

pcc commented Mar 23, 2015

Bugzilla Link 22999
Resolution FIXED
Resolved on Nov 28, 2017 15:48
Version trunk
OS Linux
CC @fhahn,@joker-eph

Extended Description

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
.zero 100000000
.global foo
foo:
bl bar
.zero 100000000
.section .text._Z1fv,"axG",%progbits,_Z1fv,comdat
.global bar
bar:
nop
$ ~/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.

@llvmbot
Copy link
Collaborator

llvmbot commented Mar 24, 2015

Having an option to use function-section and data-section with LTO would be good.

Not sure about making the default architecture dependent.

@pcc
Copy link
Contributor Author

pcc commented Mar 24, 2016

I discovered that the lack of -function-sections was inhibiting ICF. Would there be any downside to enabling function sections unconditionally? Because if not, I'd rather just do that.

@joker-eph
Copy link
Collaborator

joker-eph commented Oct 2, 2016

What is ICF?

@llvmbot
Copy link
Collaborator

llvmbot commented Oct 2, 2016

What is ICF?

Identical code/comdat folding. See lld/ELF/ICF.cpp.

@fhahn
Copy link
Contributor

fhahn commented Jun 27, 2017

I ran into this issue when bootraping Clang with LTO on ARM. Some discussion can be found here: https://reviews.llvm.org/D24644

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.

@llvmbot
Copy link
Collaborator

llvmbot commented Jul 25, 2017

I ran into this issue when bootraping Clang with LTO on ARM. Some discussion
can be found here: https://reviews.llvm.org/D24644

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.

@llvmbot
Copy link
Collaborator

llvmbot commented Nov 15, 2017

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.

@llvmbot
Copy link
Collaborator

llvmbot commented Nov 28, 2017

This was fixed by r309056, no?

@pcc
Copy link
Contributor Author

pcc commented Nov 28, 2017

Yes, I believe so.

@llvmbot
Copy link
Collaborator

llvmbot commented Nov 26, 2021

mentioned in issue llvm/llvm-bugzilla-archive#33888

1 similar comment
@pcc
Copy link
Contributor Author

pcc commented Nov 26, 2021

mentioned in issue llvm/llvm-bugzilla-archive#33888

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 9, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backend:ARM bugzilla
Projects
None yet
Development

No branches or pull requests

4 participants