On 26/01/16 17:25, Christophe Lyon wrote: > On 26 January 2016 at 18:23, Dan Murphy <dmur...@ti.com> wrote: >> Christophe >> >> >> On 01/26/2016 10:58 AM, Christophe Lyon wrote: >>> >>> On 25 January 2016 at 17:21, Dan Murphy <dmur...@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/Cihfddaf.html >>> >>> 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
