summaryrefslogtreecommitdiff
path: root/arch/powerpc/relocs_check.pl
AgeCommit message (Collapse)AuthorFilesLines
2015-03-23powerpc: Convert relocs_check to a shell script using grepStephen Rothwell1-66/+0
This runs a bit faster and removes another use of perl from the kernel build. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Acked-By: Tony Breeds <tony@bakeyournoodle.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2013-05-29Fix warning typo "CONFIG_RELCOATABLE"Paul Bolle1-5/+5
Fix typo "CONFIG_RELCOATABLE" in a warning message. While we're at it, also make that warning an actual sentence and fix comparable typos in some comments. Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-12-20powerpc: Process dynamic relocations for kernelSuzuki Poulose1-2/+12
The following patch implements the dynamic relocation processing for PPC32 kernel. relocate() accepts the target virtual address and relocates the kernel image to the same. Currently the following relocation types are handled : R_PPC_RELATIVE R_PPC_ADDR16_LO R_PPC_ADDR16_HI R_PPC_ADDR16_HA The last 3 relocations in the above list depends on value of Symbol indexed whose index is encoded in the Relocation entry. Hence we need the Symbol Table for processing such relocations. Note: The GNU ld for ppc32 produces buggy relocations for relocation types that depend on symbols. The value of the symbols with STB_LOCAL scope should be assumed to be zero. - Alan Modra Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com> Signed-off-by: Josh Poimboeuf <jpoimboe@linux.vnet.ibm.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Alan Modra <amodra@au1.ibm.com> Cc: Kumar Gala <galak@kernel.crashing.org> Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org> Signed-off-by: Josh Boyer <jwboyer@gmail.com>
2009-09-24powerpc: Check for unsupported relocs when using CONFIG_RELOCATABLETony Breeds1-0/+56
When using CONFIG_RELOCATABLE, we build the kernel as a position independent executable. The kernel then uses a little bit of relocation code to relocate itself. That code only deals with R_PPC64_RELATIVE relocations though. If for some reason you use assembly constructs such as LOAD_REG_IMMEDIATE() to load the address of a symbol, you'll generate different kinds of relocations that won't be processed properly and bad things will happen. (We have 2 such bugs today). The perl script tries to filter out "known" bad ones. It's possible that we are missing some in the case of a weak function that nobody implements, we'll see if we get false positive and fix it. Signed-off-by: Tony Breeds <tony@bakeyournoodle.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>