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.