This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
[ARM] global Thumb to ARM branches broken
- From: Christophe LYON <christophe dot lyon at st dot com>
- To: Binutils <binutils at sourceware dot org>
- Date: Wed, 03 Feb 2010 16:15:56 +0100
- Subject: [ARM] global Thumb to ARM branches broken
Hello,
It seems to me that the patch discussed in
http://sourceware.org/ml/binutils/2009-03/msg00511.html
broke the global Thumb branches by encoding the PC inside the instruction.
For instance:
.global _start
.syntax unified
.text
.thumb_func
_start:
.global bar
.space 0x300000
bl bar
.section .foo, "xa"
.arm
.type bar, %function
bar:
bx lr
is assembled into (using -march=armv5t):
00000000 <_start>:
...
300000: f4ff fffe bl ffd00000 <_start+0xffd00000>
300000: R_ARM_THM_CALL bar
Disassembly of section .foo:
00000000 <bar>:
0: e12fff1e bx lr
In turn, if one links, the resulting code is:
00008000 <_start>:
...
308000: f500 e800 blx 8004 <_start+0x4>
Disassembly of section .foo:
00308004 <bar>:
308004: e12fff1e bx lr
This is because Ramana's fix in md_pcrel_from_section() does not check
whether both sides of the branch are in the same section, or if the
destination is external.
I am working on a patch, but some inputs/comments could help.
Indeed, I am not sure what "in line with what happens with global
functions for both ARM and Thumb mode" really means (as appears in the
original post).
As I am not sure about the actual intent of that patch, I tried to
remove some parts, which did not result in regressions in the testsuite,
so some tests may be missing.
Finally, I am not sure about the new behaviour of
arm_force_relocation(): it now returns 1 in several new occurrences, but
the corresponding relocations do not appear in the object file (see
blx-local test)
I am trying to fix gas, but maybe a better fix would be in the linker
side, because the involved relocations are declared as *not* partial
inplace, but ld handles them as if they were (eg when it reads the
addend from upper_insn).
Christophe.