<html>
<head>
<base href="https://llvm.org/bugs/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - We can emit unlinkable object files when compiling large modules on (at least) ARM"
href="https://llvm.org/bugs/show_bug.cgi?id=22999">22999</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>We can emit unlinkable object files when compiling large modules on (at least) ARM
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Backend: ARM
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>peter@pcc.me.uk
</td>
</tr>
<tr>
<th>CC</th>
<td>llvmbugs@cs.uiuc.edu
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>