An error occurred fetching the project authors.
- 28 Sep, 2012 1 commit
-
-
David Howells authored
Use the mapping of Elf_[SPE]hdr, Elf_Addr, Elf_Sym, Elf_Dyn, Elf_Rel/Rela, ELF_R_TYPE() and ELF_R_SYM() to either the 32-bit version or the 64-bit version into asm-generic/module.h for all arches bar MIPS. Also, use the generic definition mod_arch_specific where possible. To this end, I've defined three new config bools: (*) HAVE_MOD_ARCH_SPECIFIC Arches define this if they don't want to use the empty generic mod_arch_specific struct. (*) MODULES_USE_ELF_RELA Arches define this if their modules can contain RELA records. This causes the Elf_Rela mapping to be emitted and allows apply_relocate_add() to be defined by the arch rather than have the core emit an error message. (*) MODULES_USE_ELF_REL Arches define this if their modules can contain REL records. This causes the Elf_Rel mapping to be emitted and allows apply_relocate() to be defined by the arch rather than have the core emit an error message. Note that it is possible to allow both REL and RELA records: m68k and mips are two arches that do this. With this, some arch asm/module.h files can be deleted entirely and replaced with a generic-y marker in the arch Kbuild file. Additionally, I have removed the bits from m32r and score that handle the unsupported type of relocation record as that's now handled centrally. Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au>
-
- 13 Aug, 2011 1 commit
-
-
Nicolas Pitre authored
This code can be removed now that MSM targets no longer need the 16-bit offsets for P2V. Signed-off-by:
Nicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
- 26 Feb, 2011 1 commit
-
-
Dave Martin authored
Loading Thumb-2 modules into an ARM kernel or vice-versa isn't guaranteed to work safely, since the kernel is not interworking- aware everywhere. This patch adds "thumb2" to the module vermagic when CONFIG_THUMB2_KERNEL is enabled, to help avoid accidental loading of modules into the wrong kernel. Signed-off-by:
Dave Martin <dave.martin@linaro.org> Acked-by:
Nicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
- 17 Feb, 2011 2 commits
-
-
Russell King authored
MSM's memory is aligned to 2MB, which is more than we can do with our existing method as we're limited to the upper 8 bits. Extend this by using two instructions to 16 bits, automatically selected when MSM is enabled. Acked-by:
Tony Lindgren <tony@atomide.com> Reviewed-by:
Nicolas Pitre <nicolas.pitre@linaro.org> Tested-by:
Nicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
This idea came from Nicolas, Eric Miao produced an initial version, which was then rewritten into this. Patch the physical to virtual translations at runtime. As we modify the code, this makes it incompatible with XIP kernels, but allows us to achieve this with minimal loss of performance. As many translations are of the form: physical = virtual + (PHYS_OFFSET - PAGE_OFFSET) virtual = physical - (PHYS_OFFSET - PAGE_OFFSET) we generate an 'add' instruction for __virt_to_phys(), and a 'sub' instruction for __phys_to_virt(). We calculate at run time (PHYS_OFFSET - PAGE_OFFSET) by comparing the address prior to MMU initialization with where it should be once the MMU has been initialized, and place this constant into the above add/sub instructions. Once we have (PHYS_OFFSET - PAGE_OFFSET), we can calculate the real PHYS_OFFSET as PAGE_OFFSET is a build-time constant, and save this for the C-mode PHYS_OFFSET variable definition to use. At present, we are unable to support Realview with Sparsemem enabled as this uses a complex mapping function, and MSM as this requires a constant which will not fit in our math instruction. Add a module version magic string for this feature to prevent incompatible modules being loaded. Tested-by:
Tony Lindgren <tony@atomide.com> Reviewed-by:
Nicolas Pitre <nicolas.pitre@linaro.org> Tested-by:
Nicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
- 01 Dec, 2010 1 commit
-
-
Russell King authored
There's no need to keep pointers to the ELF sections available while the module is loaded - we only need the section pointers while we're finding and registering the unwind tables, which can all be done during the finalize stage of loading. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
- 02 Sep, 2010 2 commits
-
-
Phil Carmody authored
Without these, exit functions cannot be stack-traced, so to speak. This implies that module unloads that perform allocations (don't laugh) will cause noisy warnings on the console when kmemleak is enabled, as it presumes that all code's call chains are traceable. Similarly, BUGs and WARN_ONs will give additional console spam. Signed-off-by:
Phil Carmody <ext-phil.2.carmody@nokia.com> Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
Phil Carmody authored
The various sections are all dealt with similarly, so factor out that common behaviour. (Incorporating Peter Huewe's fix.) Cc: Peter Huewe <peterhuewe@gmx.de> Signed-off-by:
Phil Carmody <ext-phil.2.carmody@nokia.com> Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
- 19 Feb, 2009 1 commit
-
-
Catalin Marinas authored
This patch adds ELF section parsing for the unwinding tables in loadable modules together with the PREL31 relocation symbol resolving. Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
- 02 Aug, 2008 1 commit
-
-
Russell King authored
Move platform independent header files to arch/arm/include/asm, leaving those in asm/arch* and asm/plat* alone. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
- 16 Apr, 2005 1 commit
-
-
Linus Torvalds authored
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-