| 2011-02-25 17:30:04 |
Dave Martin |
bug |
|
|
added bug |
| 2011-02-25 17:30:04 |
Dave Martin |
attachment added |
|
Compiler output demonstrating the problem https://bugs.launchpad.net/bugs/725126/+attachment/1871163/+files/inode.s |
|
| 2011-02-25 17:31:43 |
Dave Martin |
attachment added |
|
sample disassembly and relocation info https://bugs.launchpad.net/cortex-strings/+bug/725126/+attachment/1871164/+files/log.txt |
|
| 2011-02-25 17:34:27 |
Dave Martin |
description |
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. |
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. |
|
| 2011-02-25 17:35:09 |
Dave Martin |
bug task added |
|
binutils (Ubuntu) |
|
| 2011-02-25 17:36:36 |
Dave Martin |
bug task added |
|
armel-cross-toolchain-base (Ubuntu) |
|
| 2011-02-25 17:38:09 |
Dave Martin |
description |
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. |
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. |
|
| 2011-02-28 10:28:26 |
Dave Martin |
cortex-strings: status |
New |
Invalid |
|
| 2011-02-28 10:28:56 |
Dave Martin |
bug task added |
|
binutils-linaro |
|
| 2011-03-02 11:33:50 |
Dave Martin |
bug watch added |
|
http://sourceware.org/bugzilla/show_bug.cgi?id=12532 |
|
| 2011-03-02 11:33:50 |
Dave Martin |
bug task added |
|
binutils |
|
| 2011-03-23 00:43:52 |
Michael K. Edwards |
bug |
|
|
added subscriber Michael K. Edwards |
| 2011-05-26 13:19:38 |
Bug Watch Updater |
binutils: status |
Unknown |
Fix Released |
|
| 2011-05-26 13:19:38 |
Bug Watch Updater |
binutils: importance |
Unknown |
Medium |
|
| 2011-06-06 21:07:26 |
Michael Hope |
binutils-linaro: status |
New |
Won't Fix |
|
| 2011-08-26 09:50:21 |
Marcin Juszkiewicz |
armel-cross-toolchain-base (Ubuntu): status |
New |
Fix Released |
|
| 2011-08-26 09:51:38 |
Marcin Juszkiewicz |
binutils (Ubuntu): status |
New |
Fix Released |
|
| 2020-06-20 08:42:38 |
Bug Watch Updater |
bug watch added |
|
https://sourceware.org/bugzilla/show_bug.cgi?id=26141 |
|
