kernel.git/arch/powerpc/Makefile, branch linux-3.12.y

powerpc: Reject binutils 2.24 when building little endian

2017-05-09T06:19:40Z

commit 60e065f70bdb0b0e916389024922ad40f3270c96 upstream. There is a bug in binutils 2.24 which causes miscompilation if we're building little endian and using weak symbols (which the kernel does). It is fixed in binutils commit 57fa7b8c7e59 "Correct elf_merge_st_other arguments for weak symbols", which is in binutils 2.25 and has been backported to the binutils 2.24 branch and has been picked up by most distros it seems. However if we're running stock 2.24 (no extra version) then the bug is present, so check for that and bail. Signed-off-by: Michael Ellerman Signed-off-by: Jiri Slaby

powerpc: Fix 64 bit builds with binutils 2.24

2014-06-09T13:53:56Z

commit 7998eb3dc700aaf499f93f50b3d77da834ef9e1d upstream. With binutils 2.24, various 64 bit builds fail with relocation errors such as 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 The assembler maintainer says: 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. Replacing @h with @high in one strategic location fixes the relocation errors. This has to be done conditionally since the assembler either supports @h or @high but not both. Signed-off-by: Guenter Roeck Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Jiri Slaby

powerpc/e500: Set -mcpu flag for 32-bit e500

2013-08-21T01:49:56Z

Unlike 64-bit, we don't currently support multiplatform between e500 and non-e500, so the -mcpu is not configurable at this time. -msoft-float is specified when testing for -mcpu=8540 because otherwise some older toolchains will fail with "error: E500 and FPRs not supported". Signed-off-by: Scott Wood

powerpc/booke64: Use appropriate -mcpu

2013-08-21T00:55:36Z

By default use -mcpu=powerpc64 rather than -mtune=power7 Add options for e5500/e6500, with fallbacks for older compilers. Hide the POWER cpu options in booke configs. Signed-off-by: Scott Wood

powerpc/85xx: Remove -Wa,-me500

2013-08-21T00:53:10Z

This caused lwsync to be converted to sync on 64-bit (on 32-bit lwsync is generated at runtime, and so wasn't affected). Not using lwsync caused a significant slowdown on certain workloads. Setting this flag for any e500-enabled build is also not friendly to multiplatform kernels. Signed-off-by: Scott Wood

Revert "powerpc/e500: Update compilation flags with core specific options"

2013-08-14T05:00:28Z

This reverts commit c8db32c8669f7de05b820ee4934926405af52188. The commit breaks the build of all my 64-bit embedded configs. It looks like gcc-4.7.3 doesn't know about e5500. Additionally it incorrectly does -mcpu=e5500 on a config that has both e5500 and A2 support enabled. Signed-off-by: Benjamin Herrenschmidt ---

powerpc/e500: Update compilation flags with core specific options

2013-08-07T23:49:44Z

If CONFIG_E500 is enabled, the compilation flags are updated specifying the target core -mcpu=e5500/e500mc/8540 Also remove -Wa,-me500, being incompatible with -mcpu=e5500/e6500 The assembler option is redundant if the -mcpu= flag is set. The patch fixes the kernel compilation problem for e5500/e6500 when using gcc option -mcpu=e5500/e6500. Signed-off-by: Catalin Udma Signed-off-by: Scott Wood

powerpc: Avoid load of static chain register when calling nested functions through a pointer on 64bit

2013-01-10T06:01:27Z

The ppc64 ABI has a static chain register (r11) which is only used when calling nested functions through a pointer. Considering that we take a dim view of nested functions in the kernel, we have a lot of unnecessary overhead here. gcc 4.7 has an option to disable loading of r11 so lets use it. If hell freezes over and hipsters manage to litter the kernel with nested functions, gcc will give us an error message and won't simply compile bad code: You cannot take the address of a nested function if you use the -mno-pointers-to-nested-functions option. Furthermore our kernel module trampolines don't setup the static chain register so adding this option and forcing gcc to error out makes even more sense. Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt

powerpc: Build kernel with -mcmodel=medium

2013-01-10T06:00:31Z

Finally remove the two level TOC and build with -mcmodel=medium. Unfortunately we can't build modules with -mcmodel=medium due to the tricks the kernel module loader plays with percpu data: # -mcmodel=medium breaks modules because it uses 32bit offsets from # the TOC pointer to create pointers where possible. Pointers into the # percpu data area are created by this method. # # The kernel module loader relocates the percpu data section from the # original location (starting with 0xd...) to somewhere in the base # kernel percpu data space (starting with 0xc...). We need a full # 64bit relocation for this to work, hence -mcmodel=large. On older kernels we fall back to the two level TOC (-mminimal-toc) Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt

powerpc: Relocate prom_init.c on 64bit

2013-01-10T06:00:25Z

The ppc64 kernel can get loaded at any address which means our very early init code in prom_init.c must be relocatable. We do this with a pretty nasty RELOC() macro that we wrap accesses of variables with. It is very fragile and sometimes we forget to add a RELOC() to an uncommon path or sometimes a compiler change breaks it. 32bit has a much more elegant solution where we build prom_init.c with -mrelocatable and then process the relocations manually. Unfortunately we can't do the equivalent on 64bit and we would have to build the entire kernel relocatable (-pie), resulting in a large increase in kernel footprint (megabytes of relocation data). The relocation data will be marked __initdata but it still creates more pressure on our already tight memory layout at boot. Alan Modra pointed out that the 64bit ABI is relocatable even if we don't build with -pie, we just need to relocate the TOC. This patch implements that idea and relocates the TOC entries of prom_init.c. An added bonus is there are very few relocations to process which helps keep boot times on simulators down. gcc does not put 64bit integer constants into the TOC but to be safe we may want a build time script which passes through the prom_init.c TOC entries to make sure everything looks reasonable. Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt