** Attachment added: "sample disassembly and relocation info"
https://bugs.launchpad.net/cortex-strings/+bug/725126/+attachment/1871164/+files/log.txt
** Description changed:
There's no result that R_ARM_THM_JUMP11 relocation can be resolved
correctly if the symbol gets preempted.
The problem seems to strike when the compiler optimises a sibling call
to "b <label>", for which the assembler generates a b.n.
As a side-effect of the presence of this relocation, Thumb-2 kernel
modules may fail to load, since the kernel doesn't support fixing up
this relocation. I believe the kernel doesn't do any symbol preemption
processing when loading modules -- if so, the relocation is actually
redundant. But there's no way for the kernel to detect at module load
time that the relocation can safely be ignored. In kernel builds, about
1 out every 6 modules suffers from this problem. It's not clear to me
whether the method used by the kernel to link .ko objects is wrong or
not.
+
+ It seems that either the tools should support symbol preemption in this
+ scenario (implying that a short branch is not adequate to guarantee that
+ preemption will work -- i.e., a gas bug) or not (in this case the fixup
+ should be done locally and there should presumably be no relocation --
+ i.e., a different gas bug).
+
+ It appears that passing -fno-optimize-sibling-calls to GCC can work
+ around the problem by avoiding the generation of local branches to
+ global symbols, but this is clearly not the correct fix.
** Also affects: binutils (Ubuntu)
Importance: Undecided
Status: New
** Also affects: armel-cross-toolchain-base (Ubuntu)
Importance: Undecided
Status: New
** Description changed:
- There's no result that R_ARM_THM_JUMP11 relocation can be resolved
+ There's no guarantee that R_ARM_THM_JUMP11 relocation can be resolved
correctly if the symbol gets preempted.
+
+ Observed in binutils-arm-linux-gnueabi 2.20.51.20100908-0ubuntu2cross1.52.
+ Observed on binutils trunk on 2011-02-25.
The problem seems to strike when the compiler optimises a sibling call
to "b <label>", for which the assembler generates a b.n.
As a side-effect of the presence of this relocation, Thumb-2 kernel
modules may fail to load, since the kernel doesn't support fixing up
this relocation. I believe the kernel doesn't do any symbol preemption
processing when loading modules -- if so, the relocation is actually
redundant. But there's no way for the kernel to detect at module load
time that the relocation can safely be ignored. In kernel builds, about
1 out every 6 modules suffers from this problem. It's not clear to me
whether the method used by the kernel to link .ko objects is wrong or
not.
It seems that either the tools should support symbol preemption in this
scenario (implying that a short branch is not adequate to guarantee that
preemption will work -- i.e., a gas bug) or not (in this case the fixup
should be done locally and there should presumably be no relocation --
i.e., a different gas bug).
It appears that passing -fno-optimize-sibling-calls to GCC can work
around the problem by avoiding the generation of local branches to
global symbols, but this is clearly not the correct fix.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/725126
Title:
gas may assemble b to locally-defined, preemptible global symbol as
"b.n"
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
