Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
On Mon, May 12, 2014 at 03:57:34PM +1000, Benjamin Herrenschmidt wrote: This shuffles code around in exceptions-64s.S in order to allow an allmodconfig build to succeed. The main problems were: - We have a fixed hole from 0x7000 to 0x8000 for use by FW, under some circumstances the code before that would grow too big and hit the . = 0x7000 - The various attempts at making space in there would trigger cases where short conditional branches from assembly would no longer be able to reach their target. This is especially nasty when these branches reside in alternate feature sections which are appended at the end of each .o file This fixes it by essentially moving all the second level exception handlers to after the hole and moving a couple of functions near the hole itself so they sit at reachable distance of both the first level handlers (before the hole) and the alternate feature sections (end of file). In the long run, if we start hitting this again, we'll probably have to split the file in two, probably at the hole location, to keep the alt sections used by the first level handlers close to them, and move everything else further away. But for now, this will do. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org Hi Ben, what happened with this patch ? Thanks, Guenter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
On Thu, 2014-06-12 at 05:26 -0700, Guenter Roeck wrote: what happened with this patch ? Well it breaks with that binutils version of yours ... I'm trying to fix it in a better way but it's a mess... still working on it. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
On 06/12/2014 02:57 PM, Benjamin Herrenschmidt wrote: On Thu, 2014-06-12 at 05:26 -0700, Guenter Roeck wrote: what happened with this patch ? Well it breaks with that binutils version of yours ... I'm trying to fix it in a better way but it's a mess... still working on it. I updated my binutils since then, though, and the other problem I encountered (with the changed ABI) has been fixed. As it is, I'd prefer to have the patch applied, but I can understand if you don't want to apply it in case others hit the problem I had. Guenter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
PowerPC Build error with patch: powerpc/ppc64: Allow allmodconfig to build (finally !)
Hi all, I face one build error in linux-next git tree, see below: The platform is IBM P7. [root@cena01 linux-next]# make -j60 CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CALLscripts/checksyscalls.sh stdin:1232:2: warning: #warning syscall renameat2 not implemented [-Wcpp] CHK include/generated/compile.h CALLarch/powerpc/kernel/systbl_chk.sh CALLarch/powerpc/kernel/prom_init_check.sh AS arch/powerpc/kernel/head_64.o arch/powerpc/kernel/exceptions-64s.S: Assembler messages: arch/powerpc/kernel/exceptions-64s.S:269: Error: operand out of range (0x814c is not between 0x8000 and 0x7ffc) arch/powerpc/kernel/exceptions-64s.S:729: Error: operand out of range (0x814c is not between 0x8000 and 0x7ffc) make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1 make[1]: *** Waiting for unfinished jobs make: *** [arch/powerpc/kernel] Error 2 make: *** Waiting for unfinished jobs Finally, I find out that it is the commit 0be9d8b61c0c1f3c8f86292c6e237ff26acd392d powerpc/ppc64: Allow allmodconfig to build (finally !) case this error. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
On Wed, May 14, 2014 at 08:34:30AM -0700, Guenter Roeck wrote: Bummer. Confirmed, if I replace @h with @high in just one place, the builds pass with binutils 2.24. Unfortunately the same builds then fails with binutils 2.23. Any idea how to get it to compile with both old and new versions ? The standard way with GNU software would be to write a configure test, that checks for @high support in the assembler, and defines a macro if the assembler passes the check. I'm not that familiar with the linux kernel these days, but a little grepping around says that something like ashigh := $(call as-instr,lis 9$(comma)foo@high,-DHAVE_AS_ATHIGH=1) KBUILD_AFLAGS += $(ashigh) might work. Is there some predefined constant which I could possibly use for something like .if as_version_below_2.24_ orisreg,reg,(expr)@h; .else orisreg,reg,(expr)@high; .endif Thanks, Guenter -- Alan Modra Australia Development Lab, IBM ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
On 05/15/2014 02:47 AM, Alan Modra wrote: On Wed, May 14, 2014 at 08:34:30AM -0700, Guenter Roeck wrote: Bummer. Confirmed, if I replace @h with @high in just one place, the builds pass with binutils 2.24. Unfortunately the same builds then fails with binutils 2.23. Any idea how to get it to compile with both old and new versions ? The standard way with GNU software would be to write a configure test, that checks for @high support in the assembler, and defines a macro if the assembler passes the check. I'm not that familiar with the linux kernel these days, but a little grepping around says that something like ashigh := $(call as-instr,lis 9$(comma)foo@high,-DHAVE_AS_ATHIGH=1) KBUILD_AFLAGS += $(ashigh) might work. Yes, it does. Thanks! Guenter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
On Thu, 2014-05-15 at 03:46 -0700, Guenter Roeck wrote: On 05/15/2014 02:47 AM, Alan Modra wrote: On Wed, May 14, 2014 at 08:34:30AM -0700, Guenter Roeck wrote: Bummer. Confirmed, if I replace @h with @high in just one place, the builds pass with binutils 2.24. Unfortunately the same builds then fails with binutils 2.23. Any idea how to get it to compile with both old and new versions ? The standard way with GNU software would be to write a configure test, that checks for @high support in the assembler, and defines a macro if the assembler passes the check. I'm not that familiar with the linux kernel these days, but a little grepping around says that something like ashigh := $(call as-instr,lis 9$(comma)foo@high,-DHAVE_AS_ATHIGH=1) KBUILD_AFLAGS += $(ashigh) might work. Yes, it does. Care to send a patch ? :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
On 05/15/2014 05:22 AM, Benjamin Herrenschmidt wrote: On Thu, 2014-05-15 at 03:46 -0700, Guenter Roeck wrote: On 05/15/2014 02:47 AM, Alan Modra wrote: On Wed, May 14, 2014 at 08:34:30AM -0700, Guenter Roeck wrote: Bummer. Confirmed, if I replace @h with @high in just one place, the builds pass with binutils 2.24. Unfortunately the same builds then fails with binutils 2.23. Any idea how to get it to compile with both old and new versions ? The standard way with GNU software would be to write a configure test, that checks for @high support in the assembler, and defines a macro if the assembler passes the check. I'm not that familiar with the linux kernel these days, but a little grepping around says that something like ashigh := $(call as-instr,lis 9$(comma)foo@high,-DHAVE_AS_ATHIGH=1) KBUILD_AFLAGS += $(ashigh) might work. Yes, it does. Care to send a patch ? :-) Yes, working on it. Thanks, Guenter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
On Wed, May 14, 2014 at 03:22:19PM +0930, Alan Modra wrote: On Tue, May 13, 2014 at 10:16:51PM -0700, Guenter Roeck wrote: any idea what might cause this one, by any chance ? arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e': (.text+0x165ee): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_base_book3e' defined in .text section in arch/powerpc/kernel/built-in.o arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e': (.text+0x16602): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_end_book3e' defined in .text section in arch/powerpc/kernel/built-in.o arch/powerpc/kernel/built-in.o: In function `exc_debug_debug_book3e': I see this if I try to build powerpc:ppc64e_defconfig or powerpc:chroma_defconfig with gcc 4.8.2 and binutils 2.24. Blame me. I changed the ABI, something that had to be done but unfortunately happens to break the booke kernel code. When building up a 64-bit value with lis, ori, shl, oris, ori or similar sequences, you now should use @high and @higha in place of @h and @ha. @h and @ha (and their associated relocs R_PPC64_ADDR16_HI and R_PPC64_ADDR16_HA) now report overflow if the value is out of 32-bit signed range. ie. @h and @ha assume you're building a 32-bit value. This is needed to report out-of-range -mcmodel=medium toc pointer offsets in @toc@h and @toc@ha expressions, and for consistency I did the same for all other @h and @ha relocs. Bummer. Confirmed, if I replace @h with @high in just one place, the builds pass with binutils 2.24. Unfortunately the same builds then fails with binutils 2.23. Any idea how to get it to compile with both old and new versions ? Is there some predefined constant which I could possibly use for something like .if as_version_below_2.24_ orisreg,reg,(expr)@h; .else orisreg,reg,(expr)@high; .endif Thanks, Guenter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
On Mon, 2014-05-12 at 17:28 -0700, Guenter Roeck wrote: After applying this patch, I get arch/powerpc/kernel/exceptions-64s.S:269: Error: operand out of range (0x814c is not between 0x8000 and 0x7ffc) arch/powerpc/kernel/exceptions-64s.S:729: Error: operand out of range (0x814c is not between 0x8000 and 0x7ffc) with powerpc:defconfig, powerpc:allmodconfig, powerpc:cell_defconfig, and powerpc:maple_defconfig. This is on top of v3.15-rc5. Any idea what is going on ? Compiler is powerpc64-poky-linux-gcc (GCC) 4.7.2 (from poky 1.4.0-1). Interesting... works with all my test configs using 4.7.3... I don't have my tree at hand right now, I'll check what that means tomorrow see if I can find a workaround. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
On 05/13/2014 02:16 AM, Benjamin Herrenschmidt wrote: On Mon, 2014-05-12 at 17:28 -0700, Guenter Roeck wrote: After applying this patch, I get arch/powerpc/kernel/exceptions-64s.S:269: Error: operand out of range (0x814c is not between 0x8000 and 0x7ffc) arch/powerpc/kernel/exceptions-64s.S:729: Error: operand out of range (0x814c is not between 0x8000 and 0x7ffc) with powerpc:defconfig, powerpc:allmodconfig, powerpc:cell_defconfig, and powerpc:maple_defconfig. This is on top of v3.15-rc5. Any idea what is going on ? Compiler is powerpc64-poky-linux-gcc (GCC) 4.7.2 (from poky 1.4.0-1). Interesting... works with all my test configs using 4.7.3... I don't have my tree at hand right now, I'll check what that means tomorrow see if I can find a workaround. Maybe something is wrong with my toolchain. I'll try to find a more recent one. Guenter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
On Tue, May 13, 2014 at 07:16:41PM +1000, Benjamin Herrenschmidt wrote: On Mon, 2014-05-12 at 17:28 -0700, Guenter Roeck wrote: After applying this patch, I get arch/powerpc/kernel/exceptions-64s.S:269: Error: operand out of range (0x814c is not between 0x8000 and 0x7ffc) arch/powerpc/kernel/exceptions-64s.S:729: Error: operand out of range (0x814c is not between 0x8000 and 0x7ffc) with powerpc:defconfig, powerpc:allmodconfig, powerpc:cell_defconfig, and powerpc:maple_defconfig. This is on top of v3.15-rc5. Any idea what is going on ? Compiler is powerpc64-poky-linux-gcc (GCC) 4.7.2 (from poky 1.4.0-1). Interesting... works with all my test configs using 4.7.3... I don't have my tree at hand right now, I'll check what that means tomorrow see if I can find a workaround. It works for me with gcc 4.8.2 (build from yocto 1.6.0). Is asking people to use gcc 4.7.3 or later acceptable ? Guenter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
On Tue, May 13, 2014 at 07:16:41PM +1000, Benjamin Herrenschmidt wrote: On Mon, 2014-05-12 at 17:28 -0700, Guenter Roeck wrote: After applying this patch, I get arch/powerpc/kernel/exceptions-64s.S:269: Error: operand out of range (0x814c is not between 0x8000 and 0x7ffc) arch/powerpc/kernel/exceptions-64s.S:729: Error: operand out of range (0x814c is not between 0x8000 and 0x7ffc) with powerpc:defconfig, powerpc:allmodconfig, powerpc:cell_defconfig, and powerpc:maple_defconfig. This is on top of v3.15-rc5. Any idea what is going on ? Compiler is powerpc64-poky-linux-gcc (GCC) 4.7.2 (from poky 1.4.0-1). Interesting... works with all my test configs using 4.7.3... I don't have my tree at hand right now, I'll check what that means tomorrow see if I can find a workaround. Drives me crazy. With gcc 4.8.2, powerpc:allmodconfig builds, but now I get failures with ppc64e_defconfig and chroma_defconfig: arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e': (.text+0x165ee): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_base_book3e' defined in .text section in arch/powerpc/kernel/built-in.o arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e': (.text+0x16602): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_end_book3e' defined in .text section in arch/powerpc/kernel/built-in.o arch/powerpc/kernel/built-in.o: In function `exc_debug_debug_book3e': (.text+0x1679e): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_base_book3e' defined in .text section in arch/powerpc/kernel/built-in.o arch/powerpc/kernel/built-in.o: In function `exc_debug_debug_book3e': (.text+0x167b2): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_end_book3e' defined in .text section in arch/powerpc/kernel/built-in.o arch/powerpc/kernel/built-in.o: In function `skpinv': arch/powerpc/kernel/exceptions-64e.o:(.text+0x178c6): relocation truncated to fit: R_PPC64_ADDR16_HI against `.text'+178e0 arch/powerpc/kernel/built-in.o: In function `a2_tlbinit_after_linear_map': (.text+0x17966): relocation truncated to fit: R_PPC64_ADDR16_HI against `.text'+17974 arch/powerpc/kernel/built-in.o: In function `.init_core_book3e': arch/powerpc/kernel/exceptions-64e.o:(.text+0x17a7e): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_base_book3e' defined in .text section in arch/powerpc/kernel/built-in.o Worse, that happens even without your patch applied, and the patch does not make a difference :-(. Guenter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
Hi Guenter, On Tue, 13 May 2014 10:17:49 -0700 Guenter Roeck li...@roeck-us.net wrote: On Tue, May 13, 2014 at 07:16:41PM +1000, Benjamin Herrenschmidt wrote: On Mon, 2014-05-12 at 17:28 -0700, Guenter Roeck wrote: After applying this patch, I get arch/powerpc/kernel/exceptions-64s.S:269: Error: operand out of range (0x814c is not between 0x8000 and 0x7ffc) arch/powerpc/kernel/exceptions-64s.S:729: Error: operand out of range (0x814c is not between 0x8000 and 0x7ffc) with powerpc:defconfig, powerpc:allmodconfig, powerpc:cell_defconfig, and powerpc:maple_defconfig. This is on top of v3.15-rc5. Any idea what is going on ? Compiler is powerpc64-poky-linux-gcc (GCC) 4.7.2 (from poky 1.4.0-1). Interesting... works with all my test configs using 4.7.3... I don't have my tree at hand right now, I'll check what that means tomorrow see if I can find a workaround. It works for me with gcc 4.8.2 (build from yocto 1.6.0). Is asking people to use gcc 4.7.3 or later acceptable ? OK, this appears to be an assembler bug. $ cat test.s .text x: .pushsectionb, a beq y .popsection .=0x8 y: $ /opt/cross/gcc-4.6.3-nolibc/powerpc64-linux/bin/powerpc64-linux-as --version GNU assembler (GNU Binutils) 2.22 This assembler was configured for a target of `powerpc64-linux'. $ /opt/cross/gcc-4.6.3-nolibc/powerpc64-linux/bin/powerpc64-linux-as -o test.o test.s test.s: Assembler messages: test.s:4: Error: operand out of range (0x0008 is not between 0x8000 and 0x7ffc) $ /opt/cross/gcc-4.8.1-nolibc/powerpc64-linux/bin/powerpc64-linux-as --version GNU assembler (GNU Binutils) 2.23.52.20130512 This assembler was configured for a target of `powerpc64-linux'. $ /opt/cross/gcc-4.8.1-nolibc/powerpc64-linux/bin/powerpc64-linux-as -o test.o test.s (no error) Alan, can you shed light on when it was fixed? -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
On 05/13/2014 08:34 PM, Stephen Rothwell wrote: Hi Guenter, On Tue, 13 May 2014 10:17:49 -0700 Guenter Roeck li...@roeck-us.net wrote: On Tue, May 13, 2014 at 07:16:41PM +1000, Benjamin Herrenschmidt wrote: On Mon, 2014-05-12 at 17:28 -0700, Guenter Roeck wrote: After applying this patch, I get arch/powerpc/kernel/exceptions-64s.S:269: Error: operand out of range (0x814c is not between 0x8000 and 0x7ffc) arch/powerpc/kernel/exceptions-64s.S:729: Error: operand out of range (0x814c is not between 0x8000 and 0x7ffc) with powerpc:defconfig, powerpc:allmodconfig, powerpc:cell_defconfig, and powerpc:maple_defconfig. This is on top of v3.15-rc5. Any idea what is going on ? Compiler is powerpc64-poky-linux-gcc (GCC) 4.7.2 (from poky 1.4.0-1). Interesting... works with all my test configs using 4.7.3... I don't have my tree at hand right now, I'll check what that means tomorrow see if I can find a workaround. It works for me with gcc 4.8.2 (build from yocto 1.6.0). Is asking people to use gcc 4.7.3 or later acceptable ? OK, this appears to be an assembler bug. $ cat test.s .text x: .pushsectionb, a beq y .popsection .=0x8 y: $ /opt/cross/gcc-4.6.3-nolibc/powerpc64-linux/bin/powerpc64-linux-as --version GNU assembler (GNU Binutils) 2.22 This assembler was configured for a target of `powerpc64-linux'. $ /opt/cross/gcc-4.6.3-nolibc/powerpc64-linux/bin/powerpc64-linux-as -o test.o test.s test.s: Assembler messages: test.s:4: Error: operand out of range (0x0008 is not between 0x8000 and 0x7ffc) $ /opt/cross/gcc-4.8.1-nolibc/powerpc64-linux/bin/powerpc64-linux-as --version GNU assembler (GNU Binutils) 2.23.52.20130512 This assembler was configured for a target of `powerpc64-linux'. $ /opt/cross/gcc-4.8.1-nolibc/powerpc64-linux/bin/powerpc64-linux-as -o test.o test.s (no error) Alan, can you shed light on when it was fixed? Hi Stephen, any idea what might cause this one, by any chance ? arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e': (.text+0x165ee): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_base_book3e' defined in .text section in arch/powerpc/kernel/built-in.o arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e': (.text+0x16602): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_end_book3e' defined in .text section in arch/powerpc/kernel/built-in.o arch/powerpc/kernel/built-in.o: In function `exc_debug_debug_book3e': I see this if I try to build powerpc:ppc64e_defconfig or powerpc:chroma_defconfig with gcc 4.8.2 and binutils 2.24. Thanks, Guenter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
On Wed, May 14, 2014 at 01:34:34PM +1000, Stephen Rothwell wrote: OK, this appears to be an assembler bug. Agreed. Upgrade binutils! $ cat test.s .text x: .pushsectionb, a beq y .popsection .=0x8 y: $ /opt/cross/gcc-4.6.3-nolibc/powerpc64-linux/bin/powerpc64-linux-as --version GNU assembler (GNU Binutils) 2.22 This assembler was configured for a target of `powerpc64-linux'. $ /opt/cross/gcc-4.6.3-nolibc/powerpc64-linux/bin/powerpc64-linux-as -o test.o test.s test.s: Assembler messages: test.s:4: Error: operand out of range (0x0008 is not between 0x8000 and 0x7ffc) $ /opt/cross/gcc-4.8.1-nolibc/powerpc64-linux/bin/powerpc64-linux-as --version GNU assembler (GNU Binutils) 2.23.52.20130512 This assembler was configured for a target of `powerpc64-linux'. $ /opt/cross/gcc-4.8.1-nolibc/powerpc64-linux/bin/powerpc64-linux-as -o test.o test.s (no error) Alan, can you shed light on when it was fixed? 2012-11-05 https://sourceware.org/ml/binutils/2012-11/msg00043.html git show 3b8b57a9495016b2b02fbc2612dd1607d4b6f9ba The part that actually fixes this problem is Leave insn field zero -- Alan Modra Australia Development Lab, IBM ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
On Tue, May 13, 2014 at 10:16:51PM -0700, Guenter Roeck wrote: any idea what might cause this one, by any chance ? arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e': (.text+0x165ee): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_base_book3e' defined in .text section in arch/powerpc/kernel/built-in.o arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e': (.text+0x16602): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_end_book3e' defined in .text section in arch/powerpc/kernel/built-in.o arch/powerpc/kernel/built-in.o: In function `exc_debug_debug_book3e': I see this if I try to build powerpc:ppc64e_defconfig or powerpc:chroma_defconfig with gcc 4.8.2 and binutils 2.24. Blame me. I changed the ABI, something that had to be done but unfortunately happens to break the booke kernel code. When building up a 64-bit value with lis, ori, shl, oris, ori or similar sequences, you now should use @high and @higha in place of @h and @ha. @h and @ha (and their associated relocs R_PPC64_ADDR16_HI and R_PPC64_ADDR16_HA) now report overflow if the value is out of 32-bit signed range. ie. @h and @ha assume you're building a 32-bit value. This is needed to report out-of-range -mcmodel=medium toc pointer offsets in @toc@h and @toc@ha expressions, and for consistency I did the same for all other @h and @ha relocs. -- Alan Modra Australia Development Lab, IBM ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
On Mon, May 12, 2014 at 03:57:34PM +1000, Benjamin Herrenschmidt wrote: This shuffles code around in exceptions-64s.S in order to allow an allmodconfig build to succeed. The main problems were: - We have a fixed hole from 0x7000 to 0x8000 for use by FW, under some circumstances the code before that would grow too big and hit the . = 0x7000 - The various attempts at making space in there would trigger cases where short conditional branches from assembly would no longer be able to reach their target. This is especially nasty when these branches reside in alternate feature sections which are appended at the end of each .o file This fixes it by essentially moving all the second level exception handlers to after the hole and moving a couple of functions near the hole itself so they sit at reachable distance of both the first level handlers (before the hole) and the alternate feature sections (end of file). In the long run, if we start hitting this again, we'll probably have to split the file in two, probably at the hole location, to keep the alt sections used by the first level handlers close to them, and move everything else further away. But for now, this will do. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org Ben, After applying this patch, I get arch/powerpc/kernel/exceptions-64s.S:269: Error: operand out of range (0x814c is not between 0x8000 and 0x7ffc) arch/powerpc/kernel/exceptions-64s.S:729: Error: operand out of range (0x814c is not between 0x8000 and 0x7ffc) with powerpc:defconfig, powerpc:allmodconfig, powerpc:cell_defconfig, and powerpc:maple_defconfig. This is on top of v3.15-rc5. Any idea what is going on ? Compiler is powerpc64-poky-linux-gcc (GCC) 4.7.2 (from poky 1.4.0-1). Thanks, Guenter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/ppc64: Allow allmodconfig to build (finally !)
This shuffles code around in exceptions-64s.S in order to allow an allmodconfig build to succeed. The main problems were: - We have a fixed hole from 0x7000 to 0x8000 for use by FW, under some circumstances the code before that would grow too big and hit the . = 0x7000 - The various attempts at making space in there would trigger cases where short conditional branches from assembly would no longer be able to reach their target. This is especially nasty when these branches reside in alternate feature sections which are appended at the end of each .o file This fixes it by essentially moving all the second level exception handlers to after the hole and moving a couple of functions near the hole itself so they sit at reachable distance of both the first level handlers (before the hole) and the alternate feature sections (end of file). In the long run, if we start hitting this again, we'll probably have to split the file in two, probably at the hole location, to keep the alt sections used by the first level handlers close to them, and move everything else further away. But for now, this will do. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S index 3afd391..833a68d 100644 --- a/arch/powerpc/kernel/exceptions-64s.S +++ b/arch/powerpc/kernel/exceptions-64s.S @@ -533,70 +533,6 @@ do_stab_bolted_pSeries: KVM_HANDLER_PR(PACA_EXGEN, EXC_STD, 0x900) KVM_HANDLER(PACA_EXGEN, EXC_HV, 0x982) -#ifdef CONFIG_PPC_DENORMALISATION -denorm_assist: -BEGIN_FTR_SECTION -/* - * To denormalise we need to move a copy of the register to itself. - * For POWER6 do that here for all FP regs. - */ - mfmsr r10 - ori r10,r10,(MSR_FP|MSR_FE0|MSR_FE1) - xorir10,r10,(MSR_FE0|MSR_FE1) - mtmsrd r10 - sync - -#define FMR2(n) fmr (n), (n) ; fmr n+1, n+1 -#define FMR4(n) FMR2(n) ; FMR2(n+2) -#define FMR8(n) FMR4(n) ; FMR4(n+4) -#define FMR16(n) FMR8(n) ; FMR8(n+8) -#define FMR32(n) FMR16(n) ; FMR16(n+16) - FMR32(0) - -FTR_SECTION_ELSE -/* - * To denormalise we need to move a copy of the register to itself. - * For POWER7 do that here for the first 32 VSX registers only. - */ - mfmsr r10 - orisr10,r10,MSR_VSX@h - mtmsrd r10 - sync - -#define XVCPSGNDP2(n) XVCPSGNDP(n,n,n) ; XVCPSGNDP(n+1,n+1,n+1) -#define XVCPSGNDP4(n) XVCPSGNDP2(n) ; XVCPSGNDP2(n+2) -#define XVCPSGNDP8(n) XVCPSGNDP4(n) ; XVCPSGNDP4(n+4) -#define XVCPSGNDP16(n) XVCPSGNDP8(n) ; XVCPSGNDP8(n+8) -#define XVCPSGNDP32(n) XVCPSGNDP16(n) ; XVCPSGNDP16(n+16) - XVCPSGNDP32(0) - -ALT_FTR_SECTION_END_IFCLR(CPU_FTR_ARCH_206) - -BEGIN_FTR_SECTION - b denorm_done -END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_207S) -/* - * To denormalise we need to move a copy of the register to itself. - * For POWER8 we need to do that for all 64 VSX registers - */ - XVCPSGNDP32(32) -denorm_done: - mtspr SPRN_HSRR0,r11 - mtcrf 0x80,r9 - ld r9,PACA_EXGEN+EX_R9(r13) - RESTORE_PPR_PACA(PACA_EXGEN, r10) -BEGIN_FTR_SECTION - ld r10,PACA_EXGEN+EX_CFAR(r13) - mtspr SPRN_CFAR,r10 -END_FTR_SECTION_IFSET(CPU_FTR_CFAR) - ld r10,PACA_EXGEN+EX_R10(r13) - ld r11,PACA_EXGEN+EX_R11(r13) - ld r12,PACA_EXGEN+EX_R12(r13) - ld r13,PACA_EXGEN+EX_R13(r13) - HRFID - b . -#endif - .align 7 /* moved from 0xe00 */ STD_EXCEPTION_HV_OOL(0xe02, h_data_storage) @@ -623,43 +559,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_CFAR) KVM_HANDLER(PACA_EXGEN, EXC_HV, 0xf82) /* - * An interrupt came in while soft-disabled. We set paca-irq_happened, then: - * - If it was a decrementer interrupt, we bump the dec to max and and return. - * - If it was a doorbell we return immediately since doorbells are edge - * triggered and won't automatically refire. - * - else we hard disable and return. - * This is called with r10 containing the value to OR to the paca field. - */ -#define MASKED_INTERRUPT(_H) \ -masked_##_H##interrupt:\ - std r11,PACA_EXGEN+EX_R11(r13); \ - lbz r11,PACAIRQHAPPENED(r13); \ - or r11,r11,r10;\ - stb r11,PACAIRQHAPPENED(r13); \ - cmpwi r10,PACA_IRQ_DEC; \ - bne 1f; \ - lis r10,0x7fff; \ - ori r10,r10,0x; \ - mtspr SPRN_DEC,r10; \ - b 2f; \ -1: cmpwi r10,PACA_IRQ_DBELL; \ - beq 2f; \ - mfspr r10,SPRN_##_H##SRR1;\ - rldicl r10,r10,48,1; /* clear MSR_EE */\
