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 <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? >>
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: > > 1) 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 ? > 2) 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/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 > _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
