aboutsummaryrefslogtreecommitdiff
path: root/arch/powerpc/kernel/module_64.c
AgeCommit message (Collapse)Author
2009-01-22MERGE-via-pending-tracking-hist-MERGE-via-stable-tracking-MERGE-via-mokopatc ↵merge
hes-tracking-fix-stray-endmenu-patch-1232632040-1232632141 pending-tracking-hist top was MERGE-via-stable-tracking-MERGE-via-mokopatches-tracking-fix-stray-endmenu-patch-1232632040-1232632141 / fdf777a63bcb59e0dfd78bfe2c6242e01f6d4eb9 ... parent commitmessage: From: merge <null@invalid> MERGE-via-stable-tracking-hist-MERGE-via-mokopatches-tracking-fix-stray-endmenu-patch-1232632040 stable-tracking-hist top was MERGE-via-mokopatches-tracking-fix-stray-endmenu-patch-1232632040 / 90463bfd2d5a3c8b52f6e6d71024a00e052b0ced ... parent commitmessage: From: merge <null@invalid> MERGE-via-mokopatches-tracking-hist-fix-stray-endmenu-patch mokopatches-tracking-hist top was fix-stray-endmenu-patch / 3630e0be570de8057e7f8d2fe501ed353cdf34e6 ... parent commitmessage: From: Andy Green <andy@openmoko.com> fix-stray-endmenu.patch Signed-off-by: Andy Green <andy@openmoko.com>
2008-09-17Fix compile failure with non modular buildsJames Bottomley
Commit deac93df26b20cf8438339b5935b5f5643bc30c9 ("lib: Correct printk %pF to work on all architectures") broke the non modular builds by moving an essential function into modules.c. Fix this by moving it out again and into asm/sections.h as an inline. To do this, the definition of struct ppc64_opd_entry has been lifted out of modules.c and put in asm/elf.h where it belongs. Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-09-09lib: Correct printk %pF to work on all architecturesJames Bottomley
It was introduced by "vsprintf: add support for '%pS' and '%pF' pointer formats" in commit 0fe1ef24f7bd0020f29ffe287dfdb9ead33ca0b2. However, the current way its coded doesn't work on parisc64. For two reasons: 1) parisc isn't in the #ifdef and 2) parisc has a different format for function descriptors Make dereference_function_descriptor() more accommodating by allowing architecture overrides. I put the three overrides (for parisc64, ppc64 and ia64) in arch/kernel/module.c because that's where the kernel internal linker which knows how to deal with function descriptors sits. Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Tony Luck <tony.luck@intel.com> Acked-by: Kyle McMartin <kyle@mcmartin.ca> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-07-01powerpc: Add PPC_NOP_INSTR, a hash define for the preferred nop instructionMichael Ellerman
A bunch of code has hard-coded the value for a "nop" instruction, it would be nice to have a #define for it. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Acked-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-01powerpc: Move common module code into its own fileKumar Gala
Refactor common code between ppc32 and ppc64 module handling into a shared filed. Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-21[POWERPC] Optimize counting distinct entries in the relocation sectionsEmil Medve
When a module has relocation sections with tens of thousands of entries, counting the distinct/unique entries only (i.e. no duplicates) at load time can take tens of seconds and up to minutes. The sore point is the count_relocs() function which is called as part of the architecture specific module loading processing path: -> load_module() generic -> module_frob_arch_sections() arch specific -> get_plt_size() 32-bit -> get_stubs_size() 64-bit -> count_relocs() Here count_relocs is being called to find out how many distinct targets of R_PPC_REL24 relocations there are, since each distinct target needs a PLT entry or a stub created for it. The previous counting algorithm has O(n^2) complexity. Basically two solutions were proposed on the e-mail list: a hash based approach and a sort based approach. The hash based approach is the fastest (O(n)) but the has it needs additional memory and for certain corner cases it could take lots of memory due to the degeneration of the hash. One such proposal was submitted here: http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037641.html The sort based approach is slower (O(n * log n + n)) but if the sorting is done "in place" it doesn't need additional memory. This has O(n + n * log n) complexity with no additional memory requirements. This commit implements the in-place sort option. Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-12-11[POWERPC] Generic BUG for powerpcJeremy Fitzhardinge
This makes powerpc use the generic BUG machinery. The biggest reports the function name, since it is redundant with kallsyms, and not needed in general. There is an overall reduction of code, since module_32/64 duplicated several functions. Unfortunately there's no way to tell gcc that BUG won't return, so the BUG macro includes a goto loop. This will generate a real jmp instruction, which is never used. [akpm@osdl.org: build fix] [paulus@samba.org: remove infinite loop in BUG_ON] Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org> Cc: Andi Kleen <ak@muc.de> Cc: Hugh Dickens <hugh@veritas.com> Cc: Michael Ellerman <michael@ellerman.id.au> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-25[POWERPC] Support feature fixups in modulesBenjamin Herrenschmidt
This patch adds support for feature fixups in modules. This involves adding support for R_PPC64_REL64 relocs to the 64 bits module loader. It also modifies modpost.c to ignore the powerpc fixup sections (or it would warn when used in .init.text). Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Olof Johansson <olof@lixom.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-28[PATCH] powerpc64: Fix loading of modules without a .toc sectionAlan Modra
Normally, ppc64 module .ko files contain a table-of-contents (.toc) section, but if the module doesn't reference any static or external data or external procedures, it is possible for gcc/binutils to generate a .ko that doesn't have a .toc. Currently the module loader refuses to load such a module, since it needs the address of the .toc section to use in relocations. This patch fixes the problem by using the address of the .stubs section instead, which is an acceptable substitute in this situation. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-14powerpc: Move most remaining ppc64 files over to arch/powerpcPaul Mackerras
Also deletes files in arch/ppc64 that are no longer used now that we don't compile with ARCH=ppc64 any more. Signed-off-by: Paul Mackerras <paulus@samba.org>