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 <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
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: >> >> 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 >> -- ------------------ Dan Murphy _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
