Hi!
When using the linaro-4.9-2015.05 toolchain on the Linux master and on Linux stable releases I am seeing a build issue below when using the allyesconfig. This does not seem to occur on the 5.2 tool chain. We cannot move to 5.2 tool chain for our releases as they are based on 4.9.
LD init/built-in.o arch/arm/kernel/built-in.o:(.text.fixup+0x1d4): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely' arch/arm/kernel/built-in.o:(.text.fixup+0x1e0): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely' arch/arm/kernel/built-in.o:(.text.fixup+0x1ec): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely' drivers/built-in.o: In function `combiner_handle_cascade_irq': :(.text+0x834): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o :(.text+0x868): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o drivers/built-in.o: In function `hip04_irq_set_type': :(.text+0xad0): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o :(.text+0xb10): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o drivers/built-in.o: In function `hip04_raise_softirq': :(.text+0xc8c): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock_irqsave' defined in .spinlock.text section in kernel/built-in.o :(.text+0xdc8): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock_irqrestore' defined in .spinlock.text section in kernel/built-in.o drivers/built-in.o: In function `hip04_irq_set_affinity': :(.text+0xefc): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o :(.text+0xf78): additional relocation overflows omitted from the output make: *** [vmlinux] Error 1
Please advise to how to resolve this issue within the 4.9 Linaro tool chain
Dan
On 25 January 2016 at 17:21, Dan Murphy dmurphy@ti.com wrote:
Hi!
When using the linaro-4.9-2015.05 toolchain on the Linux master and on Linux stable releases I am seeing a build issue below when using the allyesconfig. This does not seem to occur on the 5.2 tool chain. We cannot move to 5.2 tool chain for our releases as they are based on 4.9.
LD init/built-in.o arch/arm/kernel/built-in.o:(.text.fixup+0x1d4): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely' arch/arm/kernel/built-in.o:(.text.fixup+0x1e0): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely' arch/arm/kernel/built-in.o:(.text.fixup+0x1ec): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely' drivers/built-in.o: In function `combiner_handle_cascade_irq': :(.text+0x834): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o :(.text+0x868): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o drivers/built-in.o: In function `hip04_irq_set_type': :(.text+0xad0): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o :(.text+0xb10): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o drivers/built-in.o: In function `hip04_raise_softirq': :(.text+0xc8c): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock_irqsave' defined in .spinlock.text section in kernel/built-in.o :(.text+0xdc8): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock_irqrestore' defined in .spinlock.text section in kernel/built-in.o drivers/built-in.o: In function `hip04_irq_set_affinity': :(.text+0xefc): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o :(.text+0xf78): additional relocation overflows omitted from the output make: *** [vmlinux] Error 1
Please advise to how to resolve this issue within the 4.9 Linaro tool chain
Hi Dan,
It would be better to report this kind of problem using our bugzilla: https://bugs.linaro.org/
I've managed to reproduce it, except for the errors with R__ARM_JUMP24. Maybe that's because I used linux-4.3.3.tar.xz.
Anyway, these errors indicate branches trying reach a function which is too far away from the call site. Normally, the linker inserts stubs (trampolines) to handle such situations, but here the .text section of drivers/built-in.o is really huge: 84247436 bytes (84MB) in my case. The linker is able to insert trampolines at section boundaries (between object files), but in this case it cannot insert one close enough, hence the error you are seeing.
The range of branch instructions is indicated for instance here: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/Cihfdda...
I'm not sure why this would no happen with the 5.2 toolchain, I haven't tried.
Christophe.
Dan
--
Dan Murphy
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
Christophe
On 01/26/2016 10:58 AM, Christophe Lyon wrote:
On 25 January 2016 at 17:21, Dan Murphy dmurphy@ti.com wrote:
Hi!
When using the linaro-4.9-2015.05 toolchain on the Linux master and on Linux stable releases I am seeing a build issue below when using the allyesconfig. This does not seem to occur on the 5.2 tool chain. We cannot move to 5.2 tool chain for our releases as they are based on 4.9.
LD init/built-in.o arch/arm/kernel/built-in.o:(.text.fixup+0x1d4): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely' arch/arm/kernel/built-in.o:(.text.fixup+0x1e0): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely' arch/arm/kernel/built-in.o:(.text.fixup+0x1ec): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely' drivers/built-in.o: In function `combiner_handle_cascade_irq': :(.text+0x834): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o :(.text+0x868): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o drivers/built-in.o: In function `hip04_irq_set_type': :(.text+0xad0): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o :(.text+0xb10): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o drivers/built-in.o: In function `hip04_raise_softirq': :(.text+0xc8c): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock_irqsave' defined in .spinlock.text section in kernel/built-in.o :(.text+0xdc8): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock_irqrestore' defined in .spinlock.text section in kernel/built-in.o drivers/built-in.o: In function `hip04_irq_set_affinity': :(.text+0xefc): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o :(.text+0xf78): additional relocation overflows omitted from the output make: *** [vmlinux] Error 1
Please advise to how to resolve this issue within the 4.9 Linaro tool chain
Hi Dan,
It would be better to report this kind of problem using our bugzilla: https://bugs.linaro.org/
I've managed to reproduce it, except for the errors with R__ARM_JUMP24. Maybe that's because I used linux-4.3.3.tar.xz.
Anyway, these errors indicate branches trying reach a function which is too far away from the call site. Normally, the linker inserts stubs (trampolines) to handle such situations, but here the .text section of drivers/built-in.o is really huge: 84247436 bytes (84MB) in my case. The linker is able to insert trampolines at section boundaries (between object files), but in this case it cannot insert one close enough, hence the error you are seeing.
Do we know if this is a linux kernel issue or a linker issue that got exposed when a patch came in?
Dan
The range of branch instructions is indicated for instance here: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/Cihfdda...
I'm not sure why this would no happen with the 5.2 toolchain, I haven't tried.
Christophe.
Dan
--
Dan Murphy
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
On 26 January 2016 at 18:23, Dan Murphy dmurphy@ti.com wrote:
Christophe
On 01/26/2016 10:58 AM, Christophe Lyon wrote:
On 25 January 2016 at 17:21, Dan Murphy dmurphy@ti.com wrote:
Hi!
When using the linaro-4.9-2015.05 toolchain on the Linux master and on Linux stable releases I am seeing a build issue below when using the allyesconfig. This does not seem to occur on the 5.2 tool chain. We cannot move to 5.2 tool chain for our releases as they are based on 4.9.
LD init/built-in.o arch/arm/kernel/built-in.o:(.text.fixup+0x1d4): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely' arch/arm/kernel/built-in.o:(.text.fixup+0x1e0): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely' arch/arm/kernel/built-in.o:(.text.fixup+0x1ec): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely' drivers/built-in.o: In function `combiner_handle_cascade_irq': :(.text+0x834): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o :(.text+0x868): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o drivers/built-in.o: In function `hip04_irq_set_type': :(.text+0xad0): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o :(.text+0xb10): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o drivers/built-in.o: In function `hip04_raise_softirq': :(.text+0xc8c): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock_irqsave' defined in .spinlock.text section in kernel/built-in.o :(.text+0xdc8): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock_irqrestore' defined in .spinlock.text section in kernel/built-in.o drivers/built-in.o: In function `hip04_irq_set_affinity': :(.text+0xefc): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o :(.text+0xf78): additional relocation overflows omitted from the output make: *** [vmlinux] Error 1
Please advise to how to resolve this issue within the 4.9 Linaro tool chain
Hi Dan,
It would be better to report this kind of problem using our bugzilla: https://bugs.linaro.org/
I've managed to reproduce it, except for the errors with R__ARM_JUMP24. Maybe that's because I used linux-4.3.3.tar.xz.
Anyway, these errors indicate branches trying reach a function which is too far away from the call site. Normally, the linker inserts stubs (trampolines) to handle such situations, but here the .text section of drivers/built-in.o is really huge: 84247436 bytes (84MB) in my case. The linker is able to insert trampolines at section boundaries (between object files), but in this case it cannot insert one close enough, hence the error you are seeing.
Do we know if this is a linux kernel issue or a linker issue that got exposed when a patch came in?
I don't know, but I'm not a kernel expert.
It's likely that the allyes config produces large object files.
Did it ever work for you?
With a known-to-work starting point we could try to bisect and identify went the problem appeared.
Christophe.
Dan
The range of branch instructions is indicated for instance here:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/Cihfdda...
I'm not sure why this would no happen with the 5.2 toolchain, I haven't tried.
Christophe.
Dan
--
Dan Murphy
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
--
Dan Murphy
On 26 January 2016 at 18:25, Christophe Lyon christophe.lyon@linaro.org wrote:
On 26 January 2016 at 18:23, Dan Murphy dmurphy@ti.com wrote:
Christophe
On 01/26/2016 10:58 AM, Christophe Lyon wrote:
On 25 January 2016 at 17:21, Dan Murphy dmurphy@ti.com wrote:
Hi!
When using the linaro-4.9-2015.05 toolchain on the Linux master and on Linux stable releases I am seeing a build issue below when using the allyesconfig. This does not seem to occur on the 5.2 tool chain. We cannot move to 5.2 tool chain for our releases as they are based on 4.9.
LD init/built-in.o arch/arm/kernel/built-in.o:(.text.fixup+0x1d4): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely' arch/arm/kernel/built-in.o:(.text.fixup+0x1e0): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely' arch/arm/kernel/built-in.o:(.text.fixup+0x1ec): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely' drivers/built-in.o: In function `combiner_handle_cascade_irq': :(.text+0x834): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o :(.text+0x868): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o drivers/built-in.o: In function `hip04_irq_set_type': :(.text+0xad0): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o :(.text+0xb10): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o drivers/built-in.o: In function `hip04_raise_softirq': :(.text+0xc8c): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock_irqsave' defined in .spinlock.text section in kernel/built-in.o :(.text+0xdc8): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock_irqrestore' defined in .spinlock.text section in kernel/built-in.o drivers/built-in.o: In function `hip04_irq_set_affinity': :(.text+0xefc): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o :(.text+0xf78): additional relocation overflows omitted from the output make: *** [vmlinux] Error 1
Please advise to how to resolve this issue within the 4.9 Linaro tool chain
Hi Dan,
It would be better to report this kind of problem using our bugzilla: https://bugs.linaro.org/
I've managed to reproduce it, except for the errors with R__ARM_JUMP24. Maybe that's because I used linux-4.3.3.tar.xz.
Anyway, these errors indicate branches trying reach a function which is too far away from the call site. Normally, the linker inserts stubs (trampolines) to handle such situations, but here the .text section of drivers/built-in.o is really huge: 84247436 bytes (84MB) in my case. The linker is able to insert trampolines at section boundaries (between object files), but in this case it cannot insert one close enough, hence the error you are seeing.
Do we know if this is a linux kernel issue or a linker issue that got exposed when a patch came in?
I don't know, but I'm not a kernel expert.
It's likely that the allyes config produces large object files.
Did it ever work for you?
With a known-to-work starting point we could try to bisect and identify went the problem appeared.
FWIW, I've just reproduced the same build error with gcc-linaro-5.2-2015.11-1, as expected.
Christophe.
Christophe.
Dan
The range of branch instructions is indicated for instance here:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/Cihfdda...
I'm not sure why this would no happen with the 5.2 toolchain, I haven't tried.
Christophe.
Dan
--
Dan Murphy
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
--
Dan Murphy
On 26/01/16 17:25, Christophe Lyon wrote:
On 26 January 2016 at 18:23, Dan Murphy dmurphy@ti.com wrote:
Christophe
On 01/26/2016 10:58 AM, Christophe Lyon wrote:
On 25 January 2016 at 17:21, Dan Murphy dmurphy@ti.com wrote:
Hi!
When using the linaro-4.9-2015.05 toolchain on the Linux master and on Linux stable releases I am seeing a build issue below when using the allyesconfig. This does not seem to occur on the 5.2 tool chain. We cannot move to 5.2 tool chain for our releases as they are based on 4.9.
LD init/built-in.o arch/arm/kernel/built-in.o:(.text.fixup+0x1d4): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely' arch/arm/kernel/built-in.o:(.text.fixup+0x1e0): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely' arch/arm/kernel/built-in.o:(.text.fixup+0x1ec): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely' drivers/built-in.o: In function `combiner_handle_cascade_irq': :(.text+0x834): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o :(.text+0x868): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o drivers/built-in.o: In function `hip04_irq_set_type': :(.text+0xad0): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o :(.text+0xb10): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o drivers/built-in.o: In function `hip04_raise_softirq': :(.text+0xc8c): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock_irqsave' defined in .spinlock.text section in kernel/built-in.o :(.text+0xdc8): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock_irqrestore' defined in .spinlock.text section in kernel/built-in.o drivers/built-in.o: In function `hip04_irq_set_affinity': :(.text+0xefc): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o :(.text+0xf78): additional relocation overflows omitted from the output make: *** [vmlinux] Error 1
Please advise to how to resolve this issue within the 4.9 Linaro tool chain
Hi Dan,
It would be better to report this kind of problem using our bugzilla: https://bugs.linaro.org/
I've managed to reproduce it, except for the errors with R__ARM_JUMP24. Maybe that's because I used linux-4.3.3.tar.xz.
Anyway, these errors indicate branches trying reach a function which is too far away from the call site. Normally, the linker inserts stubs (trampolines) to handle such situations, but here the .text section of drivers/built-in.o is really huge: 84247436 bytes (84MB) in my case. The linker is able to insert trampolines at section boundaries (between object files), but in this case it cannot insert one close enough, hence the error you are seeing.
Do we know if this is a linux kernel issue or a linker issue that got exposed when a patch came in?
I don't know, but I'm not a kernel expert.
It's likely that the allyes config produces large object files.
Did it ever work for you?
With a known-to-work starting point we could try to bisect and identify went the problem appeared.
I find it hard to believe that a compiler could generate a single object file that contained 84Mb of code, it would take an inordinate amount of code to do that even if optimizations were turned off. So that leaves two likely options:
1) The file is constructed by concatenating multiple object files, perhaps with ld -r to produce a partially linked object file. 2) The file contains some directives that are inserting large amounts of padding.
Either way, I suspect that this is going to require fixing in the Linux build system. You've hit a fundamental limit of the AArch32 architecture, as Christophe has mentioned and there's nothing at this point that the tools can do to help you.
R.
Christophe.
Dan
The range of branch instructions is indicated for instance here:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/Cihfdda...
I'm not sure why this would no happen with the 5.2 toolchain, I haven't tried.
Christophe.
Dan
--
Dan Murphy
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
--
Dan Murphy
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On 01/27/2016 08:35 AM, Richard Earnshaw wrote:
On 26/01/16 17:25, Christophe Lyon wrote:
On 26 January 2016 at 18:23, Dan Murphy dmurphy@ti.com wrote:
Christophe
On 01/26/2016 10:58 AM, Christophe Lyon wrote:
On 25 January 2016 at 17:21, Dan Murphy dmurphy@ti.com wrote:
Hi!
When using the linaro-4.9-2015.05 toolchain on the Linux master and on Linux stable releases I am seeing a build issue below when using the allyesconfig. This does not seem to occur on the 5.2 tool chain. We cannot move to 5.2 tool chain for our releases as they are based on 4.9.
LD init/built-in.o arch/arm/kernel/built-in.o:(.text.fixup+0x1d4): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely' arch/arm/kernel/built-in.o:(.text.fixup+0x1e0): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely' arch/arm/kernel/built-in.o:(.text.fixup+0x1ec): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely' drivers/built-in.o: In function `combiner_handle_cascade_irq': :(.text+0x834): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o :(.text+0x868): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o drivers/built-in.o: In function `hip04_irq_set_type': :(.text+0xad0): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o :(.text+0xb10): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o drivers/built-in.o: In function `hip04_raise_softirq': :(.text+0xc8c): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock_irqsave' defined in .spinlock.text section in kernel/built-in.o :(.text+0xdc8): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock_irqrestore' defined in .spinlock.text section in kernel/built-in.o drivers/built-in.o: In function `hip04_irq_set_affinity': :(.text+0xefc): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o :(.text+0xf78): additional relocation overflows omitted from the output make: *** [vmlinux] Error 1
Please advise to how to resolve this issue within the 4.9 Linaro tool chain
Hi Dan,
It would be better to report this kind of problem using our bugzilla: https://bugs.linaro.org/
I've managed to reproduce it, except for the errors with R__ARM_JUMP24. Maybe that's because I used linux-4.3.3.tar.xz.
Anyway, these errors indicate branches trying reach a function which is too far away from the call site. Normally, the linker inserts stubs (trampolines) to handle such situations, but here the .text section of drivers/built-in.o is really huge: 84247436 bytes (84MB) in my case. The linker is able to insert trampolines at section boundaries (between object files), but in this case it cannot insert one close enough, hence the error you are seeing.
Do we know if this is a linux kernel issue or a linker issue that got exposed when a patch came in?
I don't know, but I'm not a kernel expert.
It's likely that the allyes config produces large object files.
Did it ever work for you?
Still a valid question
With a known-to-work starting point we could try to bisect and identify went the problem appeared.
I find it hard to believe that a compiler could generate a single object file that contained 84Mb of code, it would take an inordinate amount of code to do that even if optimizations were turned off. So that leaves two likely options:
- The file is constructed by concatenating multiple object files,
perhaps with ld -r to produce a partially linked object file.
Which the kernel build does for each sub-directory (recursively) This is the case of drivers/built-in.o This is not new, the kernel has been using this technique for years.
Does the trampoline generation not happen for ld -r ?
- The file contains some directives that are inserting large amounts of
padding.
- or - 3) using incbin to include a binary file into the object file This is used when building a compressed kernel and other places.
Either way, I suspect that this is going to require fixing in the Linux build system. You've hit a fundamental limit of the AArch32 architecture, as Christophe has mentioned and there's nothing at this point that the tools can do to help you.
R.
Christophe.
Dan
The range of branch instructions is indicated for instance here:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/Cihfdda...
I'm not sure why this would no happen with the 5.2 toolchain, I haven't tried.
Christophe.
Dan
--
Dan Murphy
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
--
Dan Murphy
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
On 27/01/16 14:52, William Mills wrote:
On 01/27/2016 08:35 AM, Richard Earnshaw wrote:
On 26/01/16 17:25, Christophe Lyon wrote:
On 26 January 2016 at 18:23, Dan Murphy dmurphy@ti.com wrote:
Christophe
On 01/26/2016 10:58 AM, Christophe Lyon wrote:
On 25 January 2016 at 17:21, Dan Murphy dmurphy@ti.com wrote:
Hi!
When using the linaro-4.9-2015.05 toolchain on the Linux master and on Linux stable releases I am seeing a build issue below when using the allyesconfig. This does not seem to occur on the 5.2 tool chain. We cannot move to 5.2 tool chain for our releases as they are based on 4.9.
LD init/built-in.o arch/arm/kernel/built-in.o:(.text.fixup+0x1d4): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely' arch/arm/kernel/built-in.o:(.text.fixup+0x1e0): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely' arch/arm/kernel/built-in.o:(.text.fixup+0x1ec): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely' drivers/built-in.o: In function `combiner_handle_cascade_irq': :(.text+0x834): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o :(.text+0x868): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o drivers/built-in.o: In function `hip04_irq_set_type': :(.text+0xad0): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o :(.text+0xb10): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o drivers/built-in.o: In function `hip04_raise_softirq': :(.text+0xc8c): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock_irqsave' defined in .spinlock.text section in kernel/built-in.o :(.text+0xdc8): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock_irqrestore' defined in .spinlock.text section in kernel/built-in.o drivers/built-in.o: In function `hip04_irq_set_affinity': :(.text+0xefc): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o :(.text+0xf78): additional relocation overflows omitted from the output make: *** [vmlinux] Error 1
Please advise to how to resolve this issue within the 4.9 Linaro tool chain
Hi Dan,
It would be better to report this kind of problem using our bugzilla: https://bugs.linaro.org/
I've managed to reproduce it, except for the errors with R__ARM_JUMP24. Maybe that's because I used linux-4.3.3.tar.xz.
Anyway, these errors indicate branches trying reach a function which is too far away from the call site. Normally, the linker inserts stubs (trampolines) to handle such situations, but here the .text section of drivers/built-in.o is really huge: 84247436 bytes (84MB) in my case. The linker is able to insert trampolines at section boundaries (between object files), but in this case it cannot insert one close enough, hence the error you are seeing.
Do we know if this is a linux kernel issue or a linker issue that got exposed when a patch came in?
I don't know, but I'm not a kernel expert.
It's likely that the allyes config produces large object files.
Did it ever work for you?
Still a valid question
With a known-to-work starting point we could try to bisect and identify went the problem appeared.
I find it hard to believe that a compiler could generate a single object file that contained 84Mb of code, it would take an inordinate amount of code to do that even if optimizations were turned off. So that leaves two likely options:
- The file is constructed by concatenating multiple object files,
perhaps with ld -r to produce a partially linked object file.
Which the kernel build does for each sub-directory (recursively) This is the case of drivers/built-in.o This is not new, the kernel has been using this technique for years.
Does the trampoline generation not happen for ld -r ?
I don't believe so. It would be hard to do it then anyway because the type of trampoline (and whether a trampoline is even permitted) depends on the the symbol that the code resolves to and that probably isn't known during the pre-linking step.
R.
- The file contains some directives that are inserting large amounts of
padding.
- or -
- using incbin to include a binary file into the object file
This is used when building a compressed kernel and other places.
Either way, I suspect that this is going to require fixing in the Linux build system. You've hit a fundamental limit of the AArch32 architecture, as Christophe has mentioned and there's nothing at this point that the tools can do to help you.
R.
Christophe.
Dan
The range of branch instructions is indicated for instance here:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/Cihfdda...
I'm not sure why this would no happen with the 5.2 toolchain, I haven't tried.
Christophe.
Dan
--
Dan Murphy
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
--
Dan Murphy
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On 27 January 2016 at 15:57, Richard Earnshaw Richard.Earnshaw@arm.com wrote:
On 27/01/16 14:52, William Mills wrote:
On 01/27/2016 08:35 AM, Richard Earnshaw wrote:
On 26/01/16 17:25, Christophe Lyon wrote:
On 26 January 2016 at 18:23, Dan Murphy dmurphy@ti.com wrote:
Christophe
On 01/26/2016 10:58 AM, Christophe Lyon wrote:
On 25 January 2016 at 17:21, Dan Murphy dmurphy@ti.com wrote: > > Hi! > > When using the linaro-4.9-2015.05 toolchain on the Linux master and on > Linux stable releases > I am seeing a build issue below when using the allyesconfig. This does > not seem to occur on the 5.2 tool chain. > We cannot move to 5.2 tool chain for our releases as they are based on > 4.9. > > LD init/built-in.o > arch/arm/kernel/built-in.o:(.text.fixup+0x1d4): relocation truncated to > fit: R_ARM_JUMP24 against `.text.unlikely' > arch/arm/kernel/built-in.o:(.text.fixup+0x1e0): relocation truncated to > fit: R_ARM_JUMP24 against `.text.unlikely' > arch/arm/kernel/built-in.o:(.text.fixup+0x1ec): relocation truncated to > fit: R_ARM_JUMP24 against `.text.unlikely' > drivers/built-in.o: In function `combiner_handle_cascade_irq': > :(.text+0x834): relocation truncated to fit: R_ARM_CALL against symbol > `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o > :(.text+0x868): relocation truncated to fit: R_ARM_CALL against symbol > `_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o > drivers/built-in.o: In function `hip04_irq_set_type': > :(.text+0xad0): relocation truncated to fit: R_ARM_CALL against symbol > `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o > :(.text+0xb10): relocation truncated to fit: R_ARM_CALL against symbol > `_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o > drivers/built-in.o: In function `hip04_raise_softirq': > :(.text+0xc8c): relocation truncated to fit: R_ARM_CALL against symbol > `_raw_spin_lock_irqsave' defined in .spinlock.text section in > kernel/built-in.o > :(.text+0xdc8): relocation truncated to fit: R_ARM_CALL against symbol > `_raw_spin_unlock_irqrestore' defined in .spinlock.text section in > kernel/built-in.o > drivers/built-in.o: In function `hip04_irq_set_affinity': > :(.text+0xefc): relocation truncated to fit: R_ARM_CALL against symbol > `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o > :(.text+0xf78): additional relocation overflows omitted from the output > make: *** [vmlinux] Error 1 > > Please advise to how to resolve this issue within the 4.9 Linaro tool > chain
Hi Dan,
It would be better to report this kind of problem using our bugzilla: https://bugs.linaro.org/
I've managed to reproduce it, except for the errors with R__ARM_JUMP24. Maybe that's because I used linux-4.3.3.tar.xz.
Anyway, these errors indicate branches trying reach a function which is too far away from the call site. Normally, the linker inserts stubs (trampolines) to handle such situations, but here the .text section of drivers/built-in.o is really huge: 84247436 bytes (84MB) in my case. The linker is able to insert trampolines at section boundaries (between object files), but in this case it cannot insert one close enough, hence the error you are seeing.
Do we know if this is a linux kernel issue or a linker issue that got exposed when a patch came in?
I don't know, but I'm not a kernel expert.
It's likely that the allyes config produces large object files.
Did it ever work for you?
Still a valid question
With a known-to-work starting point we could try to bisect and identify went the problem appeared.
I find it hard to believe that a compiler could generate a single object file that contained 84Mb of code, it would take an inordinate amount of code to do that even if optimizations were turned off. So that leaves two likely options:
- The file is constructed by concatenating multiple object files,
perhaps with ld -r to produce a partially linked object file.
Which the kernel build does for each sub-directory (recursively) This is the case of drivers/built-in.o This is not new, the kernel has been using this technique for years.
Does the trampoline generation not happen for ld -r ?
I don't believe so. It would be hard to do it then anyway because the type of trampoline (and whether a trampoline is even permitted) depends on the the symbol that the code resolves to and that probably isn't known during the pre-linking step.
I confirm the trampolines are not inserted for ld -r.
Maybe using -ffunction-sections would help?
Christophe.
R.
- The file contains some directives that are inserting large amounts of
padding.
- or -
- using incbin to include a binary file into the object file
This is used when building a compressed kernel and other places.
Either way, I suspect that this is going to require fixing in the Linux build system. You've hit a fundamental limit of the AArch32 architecture, as Christophe has mentioned and there's nothing at this point that the tools can do to help you.
R.
Christophe.
Dan
The range of branch instructions is indicated for instance here:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/Cihfdda...
I'm not sure why this would no happen with the 5.2 toolchain, I haven't tried.
Christophe.
> Dan > > -- > ------------------ > Dan Murphy > > _______________________________________________ > linaro-toolchain mailing list > linaro-toolchain@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/linaro-toolchain
--
Dan Murphy
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On Wed, Jan 27, 2016 at 8:37 AM, Christophe Lyon christophe.lyon@linaro.org wrote:
I confirm the trampolines are not inserted for ld -r.
We can't insert the trampolines with ld -r. We don't have all of the symbols required for this with a relocatable link. Also, for the symbols we do have, we don't know the final addresses, so we don't know which branches/calls will be out of range.
Maybe using -ffunction-sections would help?
Using -mlong-calls might be easier. You would only want this enabled for a allyesconfig build of course. This should solve the out-of-range calls to the spin lock functions. it probably doesn't help for the out-of-range branches to the .text.unlikely sections, but this is a gcc optimization that can be disabled with -fno-reorder-functions. This is again something you would only want for an allyesconfig build.
Jim
On 27/01/16 16:57, Jim Wilson wrote:
On Wed, Jan 27, 2016 at 8:37 AM, Christophe Lyon christophe.lyon@linaro.org wrote:
I confirm the trampolines are not inserted for ld -r.
We can't insert the trampolines with ld -r. We don't have all of the symbols required for this with a relocatable link. Also, for the symbols we do have, we don't know the final addresses, so we don't know which branches/calls will be out of range.
Maybe using -ffunction-sections would help?
Using -mlong-calls might be easier. You would only want this enabled for a allyesconfig build of course. This should solve the out-of-range calls to the spin lock functions. it probably doesn't help for the out-of-range branches to the .text.unlikely sections, but this is a gcc optimization that can be disabled with -fno-reorder-functions. This is again something you would only want for an allyesconfig build.
Jim
Long calls would probably solve the problem, but would likely be horribly expensive in performance.
The best solution would be to have an option to prevent ld -r from merging like-named sections (instead just aggregating multiple sections with similar names into one object file). This is possible in ELF.
R. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On Wed, Jan 27, 2016 at 9:30 AM, Richard Earnshaw Richard.Earnshaw@arm.com wrote:
Long calls would probably solve the problem, but would likely be horribly expensive in performance.
An allyesconfig is presumably only to verify that you haven't accidentally broken any build config with a patch, so performance should not be a concern.
The best solution would be to have an option to prevent ld -r from merging like-named sections (instead just aggregating multiple sections with similar names into one object file). This is possible in ELF.
Another way to do this is to make an archive file instead of using ld -r, and then use --whole-archive <archivefile> --no-whole-archive. That would avoid the need for linker changes.
While it might be possible to make an ELF file with multiple sections with the same name, that would likely confuse lots of tools, and require cascading changes, which could get ugly.
Jim
On 27 January 2016 at 18:49, Jim Wilson jim.wilson@linaro.org wrote:
On Wed, Jan 27, 2016 at 9:30 AM, Richard Earnshaw Richard.Earnshaw@arm.com wrote:
Long calls would probably solve the problem, but would likely be horribly expensive in performance.
An allyesconfig is presumably only to verify that you haven't accidentally broken any build config with a patch, so performance should not be a concern.
The best solution would be to have an option to prevent ld -r from merging like-named sections (instead just aggregating multiple sections with similar names into one object file). This is possible in ELF.
Another way to do this is to make an archive file instead of using ld -r, and then use --whole-archive <archivefile> --no-whole-archive. That would avoid the need for linker changes.
While it might be possible to make an ELF file with multiple sections with the same name, that would likely confuse lots of tools, and require cascading changes, which could get ugly.
Jim
I've just tried with-ffunction-sections, but I got: drivers/built-in.o:(.text.fixup+0x264): relocation truncated to fit: R_ARM_JUMP24 against `.text.armada_gem_pwrite_ioctl' drivers/built-in.o:(.text.fixup+0x270): relocation truncated to fit: R_ARM_JUMP24 against `.text.armada_gem_pwrite_ioctl' drivers/built-in.o:(.text.fixup+0x278): relocation truncated to fit: R_ARM_JUMP24 against `.text.scsi_ioctl' drivers/built-in.o:(.text.fixup+0x280): relocation truncated to fit: R_ARM_JUMP24 against `.text.scsi_ioctl' drivers/built-in.o:(.text.fixup+0x288): relocation truncated to fit: R_ARM_JUMP24 against `.text.sg_ioctl' drivers/built-in.o:(.text.fixup+0x290): relocation truncated to fit: R_ARM_JUMP24 against `.text.sg_ioctl' drivers/built-in.o:(.text.fixup+0x298): relocation truncated to fit: R_ARM_JUMP24 against `.text.sg_ioctl' drivers/built-in.o:(.text.fixup+0x2a0): relocation truncated to fit: R_ARM_JUMP24 against `.text.sg_ioctl' drivers/built-in.o:(.text.fixup+0x2a8): relocation truncated to fit: R_ARM_JUMP24 against `.text.sg_ioctl' drivers/built-in.o:(.text.fixup+0x2b0): relocation truncated to fit: R_ARM_JUMP24 against `.text.sg_ioctl' drivers/built-in.o:(.text.fixup+0x2b8): additional relocation overflows omitted from the output
Now, with -mlong-calls, I got: drivers/built-in.o: In function `atom_op_mul': sunxi_sid.c:(.text+0xa2c334): relocation truncated to fit: R_ARM_CALL against symbol `__gnu_mcount_nc' defined in .text section in arch/arm/kernel/built-in.o drivers/built-in.o: In function `atom_op_move': sunxi_sid.c:(.text+0xa2c4d4): relocation truncated to fit: R_ARM_CALL against symbol `__gnu_mcount_nc' defined in .text section in arch/arm/kernel/built-in.o drivers/built-in.o: In function `atom_op_mask': sunxi_sid.c:(.text+0xa2c830): relocation truncated to fit: R_ARM_CALL against symbol `__gnu_mcount_nc' defined in .text section in arch/arm/kernel/built-in.o drivers/built-in.o: In function `atom_op_div': sunxi_sid.c:(.text+0xa2cb1c): relocation truncated to fit: R_ARM_CALL against symbol `__gnu_mcount_nc' defined in .text section in arch/arm/kernel/built-in.o drivers/built-in.o: In function `atom_op_compare': sunxi_sid.c:(.text+0xa2cd10): relocation truncated to fit: R_ARM_CALL against symbol `__gnu_mcount_nc' defined in .text section in arch/arm/kernel/built-in.o drivers/built-in.o: In function `atom_op_and': sunxi_sid.c:(.text+0xa2cfa0): relocation truncated to fit: R_ARM_CALL against symbol `__gnu_mcount_nc' defined in .text section in arch/arm/kernel/built-in.o drivers/built-in.o: In function `atom_op_add': sunxi_sid.c:(.text+0xa2d1e0): relocation truncated to fit: R_ARM_CALL against symbol `__gnu_mcount_nc' defined in .text section in arch/arm/kernel/built-in.o drivers/built-in.o: In function `atom_op_delay': sunxi_sid.c:(.text+0xa2d41c): relocation truncated to fit: R_ARM_CALL against symbol `__gnu_mcount_nc' defined in .text section in arch/arm/kernel/built-in.o drivers/built-in.o: In function `atom_op_jump': sunxi_sid.c:(.text+0xa2d624): relocation truncated to fit: R_ARM_CALL against symbol `__gnu_mcount_nc' defined in .text section in arch/arm/kernel/built-in.o drivers/built-in.o: In function `amdgpu_atom_execute_table_locked': sunxi_sid.c:(.text+0xa2da2c): relocation truncated to fit: R_ARM_CALL against symbol `__gnu_mcount_nc' defined in .text section in arch/arm/kernel/built-in.o
Which is surprising. But maybe I didn't add -mlong-calls where I should have and some files were compiled without it, or there are asm fragments using direct calls?
So... it looks like there is no straight forward route.
Christophe.
On Thu, Jan 28, 2016 at 7:15 AM, Christophe Lyon christophe.lyon@linaro.org wrote:
Now, with -mlong-calls, I got: drivers/built-in.o: In function `atom_op_mul': sunxi_sid.c:(.text+0xa2c334): relocation truncated to fit: R_ARM_CALL against symbol `__gnu_mcount_nc' defined in .text section in arch/arm/kernel/built-in.o
This is a minor arm port bug. Use both -mlong-calls and -pg and you get bl __gnu_mcount_nc instead of the long call to mcount that I expected. The MIPS port does get this right, and uses a longcall for mcount if longcalls are enabled.
But you got me thinking about this. There is a bit of assembly code in the kernel, and you might run into other similar issues that would require kernel changes to make this work, so this isn't a trivial solution, but I think it is still doable if someone cared enough.
I also noticed that the kernel has support for dynamically modifying code to enable/disable the profiling calls. That would need changing to support long calls if you want this kernel to work. But if an allyesconfig is only to verify that the kernel builds, this may not matter.
Jim
On 28 January 2016 at 22:20, Jim Wilson jim.wilson@linaro.org wrote:
This is a minor arm port bug. Use both -mlong-calls and -pg and you get bl __gnu_mcount_nc instead of the long call to mcount that I expected. The MIPS port does get this right, and uses a longcall for mcount if longcalls are enabled.
Hi Jim,
We have this bug in LLVM:
https://llvm.org/bugs/show_bug.cgi?id=23969
Which deals with the problems of mcount messing up the prologue, and it seems to affect both kernel and chromium.
I was delaying the decision to move to __gnu_mcount_nc on ARM unconditionally, but if GCC requires the -mlong-calls option, then I think we could make it work very easily.
Is this in line of what you were suggesting, or am I crossing the wires here?
cheers, --renato
On Thu, Jan 28, 2016 at 2:26 PM, Renato Golin renato.golin@linaro.org wrote:
We have this bug in LLVM: https://llvm.org/bugs/show_bug.cgi?id=23969 Which deals with the problems of mcount messing up the prologue, and it seems to affect both kernel and chromium.
This is an unrelated problem.
I was delaying the decision to move to __gnu_mcount_nc on ARM unconditionally, but if GCC requires the -mlong-calls option, then I think we could make it work very easily.
GCC does not require -mlong-calls.
This is a specific problem related to the kernel allyesconfig option which enables everything, resulting in a kernel so large, with ld -r combined text sections so large, that we get out-of-range calls that linker relaxation can't fix. I was suggesting -mlong-calls as a workaround, except that it turns out that -mlong-calls -pg doesn't work, because we always emit a short-call to mcount, even when -mlong-calls is specified. That is a minor bug in the gcc ARM port.
Jim
On 01/27/2016 08:52 AM, William Mills wrote:
On 01/27/2016 08:35 AM, Richard Earnshaw wrote:
On 26/01/16 17:25, Christophe Lyon wrote:
On 26 January 2016 at 18:23, Dan Murphy dmurphy@ti.com wrote:
Christophe
On 01/26/2016 10:58 AM, Christophe Lyon wrote:
On 25 January 2016 at 17:21, Dan Murphy dmurphy@ti.com wrote:
Hi!
When using the linaro-4.9-2015.05 toolchain on the Linux master and on Linux stable releases I am seeing a build issue below when using the allyesconfig. This does not seem to occur on the 5.2 tool chain. We cannot move to 5.2 tool chain for our releases as they are based on 4.9.
LD init/built-in.o arch/arm/kernel/built-in.o:(.text.fixup+0x1d4): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely' arch/arm/kernel/built-in.o:(.text.fixup+0x1e0): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely' arch/arm/kernel/built-in.o:(.text.fixup+0x1ec): relocation truncated to fit: R_ARM_JUMP24 against `.text.unlikely' drivers/built-in.o: In function `combiner_handle_cascade_irq': :(.text+0x834): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o :(.text+0x868): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o drivers/built-in.o: In function `hip04_irq_set_type': :(.text+0xad0): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o :(.text+0xb10): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock' defined in .spinlock.text section in kernel/built-in.o drivers/built-in.o: In function `hip04_raise_softirq': :(.text+0xc8c): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock_irqsave' defined in .spinlock.text section in kernel/built-in.o :(.text+0xdc8): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_unlock_irqrestore' defined in .spinlock.text section in kernel/built-in.o drivers/built-in.o: In function `hip04_irq_set_affinity': :(.text+0xefc): relocation truncated to fit: R_ARM_CALL against symbol `_raw_spin_lock' defined in .spinlock.text section in kernel/built-in.o :(.text+0xf78): additional relocation overflows omitted from the output make: *** [vmlinux] Error 1
Please advise to how to resolve this issue within the 4.9 Linaro tool chain
Hi Dan,
It would be better to report this kind of problem using our bugzilla: https://bugs.linaro.org/
I've managed to reproduce it, except for the errors with R__ARM_JUMP24. Maybe that's because I used linux-4.3.3.tar.xz.
Anyway, these errors indicate branches trying reach a function which is too far away from the call site. Normally, the linker inserts stubs (trampolines) to handle such situations, but here the .text section of drivers/built-in.o is really huge: 84247436 bytes (84MB) in my case. The linker is able to insert trampolines at section boundaries (between object files), but in this case it cannot insert one close enough, hence the error you are seeing.
Do we know if this is a linux kernel issue or a linker issue that got exposed when a patch came in?
I don't know, but I'm not a kernel expert.
It's likely that the allyes config produces large object files.
Did it ever work for you?
Still a valid question
I went back to v4.1 tag from Linus and the build still fails for allyes.
I tried to reproduce my 5.2 results with the arm-none toolchain but the kernel does not even compile with that compiler. Not sure if the Linux kernel is supposed to compile with arm-none toolchain.
Dan
With a known-to-work starting point we could try to bisect and identify went the problem appeared.
I find it hard to believe that a compiler could generate a single object file that contained 84Mb of code, it would take an inordinate amount of code to do that even if optimizations were turned off. So that leaves two likely options:
- The file is constructed by concatenating multiple object files,
perhaps with ld -r to produce a partially linked object file.
Which the kernel build does for each sub-directory (recursively) This is the case of drivers/built-in.o This is not new, the kernel has been using this technique for years.
Does the trampoline generation not happen for ld -r ?
- The file contains some directives that are inserting large amounts of
padding.
- or -
- using incbin to include a binary file into the object file
This is used when building a compressed kernel and other places.
Either way, I suspect that this is going to require fixing in the Linux build system. You've hit a fundamental limit of the AArch32 architecture, as Christophe has mentioned and there's nothing at this point that the tools can do to help you.
R.
Christophe.
Dan
The range of branch instructions is indicated for instance here:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/Cihfdda...
I'm not sure why this would no happen with the 5.2 toolchain, I haven't tried.
Christophe.
Dan
--
Dan Murphy
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
--
Dan Murphy
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
linaro-toolchain@lists.linaro.org
-
Christophe Lyon -
Dan Murphy -
Jim Wilson -
Renato Golin -
Richard Earnshaw -
William Mills