1. 21 1月, 2016 1 次提交
    • A
      powerpc: Simplify module TOC handling · c153693d
      Alan Modra 提交于
      PowerPC64 uses the symbol .TOC. much as other targets use
      _GLOBAL_OFFSET_TABLE_. It identifies the value of the GOT pointer (or in
      powerpc parlance, the TOC pointer). Global offset tables are generally
      local to an executable or shared library, or in the kernel, module. Thus
      it does not make sense for a module to resolve a relocation against
      .TOC. to the kernel's .TOC. value. A module has its own .TOC., and
      indeed the powerpc64 module relocation processing ignores the kernel
      value of .TOC. and instead calculates a module-local value.
      
      This patch removes code involved in exporting the kernel .TOC., tweaks
      modpost to ignore an undefined .TOC., and the module loader to twiddle
      the section symbol so that .TOC. isn't seen as undefined.
      
      Note that if the kernel was compiled with -msingle-pic-base then ELFv2
      would not have function global entry code setting up r2. In that case
      the module call stubs would need to be modified to set up r2 using the
      kernel .TOC. value, requiring some of this code to be reinstated.
      
      mpe: Furthermore a change in binutils master (not yet released) causes
      the current way we handle the TOC to no longer work when building with
      MODVERSIONS=y and RELOCATABLE=n. The symptom is that modules can not be
      loaded due to there being no version found for TOC.
      
      Cc: stable@vger.kernel.org # 3.16+
      Signed-off-by: NAlan Modra <amodra@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      c153693d
  2. 13 1月, 2016 1 次提交
    • U
      powerpc/module: Handle R_PPC64_ENTRY relocations · a61674bd
      Ulrich Weigand 提交于
      GCC 6 will include changes to generated code with -mcmodel=large,
      which is used to build kernel modules on powerpc64le.  This was
      necessary because the large model is supposed to allow arbitrary
      sizes and locations of the code and data sections, but the ELFv2
      global entry point prolog still made the unconditional assumption
      that the TOC associated with any particular function can be found
      within 2 GB of the function entry point:
      
      func:
      	addis r2,r12,(.TOC.-func)@ha
      	addi  r2,r2,(.TOC.-func)@l
      	.localentry func, .-func
      
      To remove this assumption, GCC will now generate instead this global
      entry point prolog sequence when using -mcmodel=large:
      
      	.quad .TOC.-func
      func:
      	.reloc ., R_PPC64_ENTRY
      	ld    r2, -8(r12)
      	add   r2, r2, r12
      	.localentry func, .-func
      
      The new .reloc triggers an optimization in the linker that will
      replace this new prolog with the original code (see above) if the
      linker determines that the distance between .TOC. and func is in
      range after all.
      
      Since this new relocation is now present in module object files,
      the kernel module loader is required to handle them too.  This
      patch adds support for the new relocation and implements the
      same optimization done by the GNU linker.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NUlrich Weigand <ulrich.weigand@de.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      a61674bd
  3. 02 10月, 2014 1 次提交
  4. 25 6月, 2014 1 次提交
    • L
      powerpc/module: Fix TOC symbol CRC · c2cbcf53
      Laurent Dufour 提交于
      The commit 71ec7c55 introduced the magic symbol ".TOC." for ELFv2 ABI.
      This symbol is built manually and has no CRC value computed. A zero value
      is put in the CRC section to avoid modpost complaining about a missing CRC.
      Unfortunately, this breaks the kernel module loading when the kernel is
      relocated (kdump case for instance) because of the relocation applied to
      the kcrctab values.
      
      This patch compute a CRC value for the TOC symbol which will match the one
      compute by the kernel when it is relocated - aka '0 - relocate_start' done in
      maybe_relocated called by check_version (module.c).
      Signed-off-by: NLaurent Dufour <ldufour@linux.vnet.ibm.com>
      Cc: Anton Blanchard <anton@samba.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      c2cbcf53
  5. 20 5月, 2014 1 次提交
  6. 23 4月, 2014 11 次提交
  7. 30 10月, 2013 1 次提交
  8. 11 10月, 2013 1 次提交
  9. 10 1月, 2013 1 次提交
    • A
      powerpc: Build kernel with -mcmodel=medium · 1fbe9cf2
      Anton Blanchard 提交于
      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: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      1fbe9cf2
  10. 24 7月, 2011 1 次提交
  11. 23 2月, 2009 1 次提交
    • K
      powerpc: Unify opcode definitions and support · 16c57b36
      Kumar Gala 提交于
      Create a new header that becomes a single location for defining PowerPC
      opcodes used by code that is either generationg instructions
      at runtime (fixups, debug, etc.), emulating instructions, or just
      compiling instructions old assemblers don't know about.
      
      We currently don't handle the floating point emulation or alignment decode
      as both are better handled by the specific decode support they already
      have.
      
      Added support for the new dcbzl, dcbal, msgsnd, tlbilx, & wait instructions
      since older assemblers don't know about them.
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      16c57b36
  12. 21 11月, 2008 1 次提交
    • S
      powerpc/ppc64: ftrace, handle module trampolines for dyn ftrace · f48cb8b4
      Steven Rostedt 提交于
      Impact: Allow 64 bit PowerPC to trace modules with dynamic ftrace
      
      This adds code to handle the PPC64 module trampolines, and allows for
      PPC64 to use dynamic ftrace.
      
      Thanks to Paul Mackerras for these updates:
      
        - fix the mod and rec->arch.mod NULL checks.
        - fix to is_bl_op compare.
      
      Thanks to Milton Miller for:
      
        - finding the nasty race with using two nops, and recommending
          instead that I use a branch 8 forward.
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      f48cb8b4
  13. 18 9月, 2008 1 次提交
  14. 10 9月, 2008 1 次提交
  15. 01 7月, 2008 2 次提交
  16. 21 12月, 2007 1 次提交
    • E
      [POWERPC] Optimize counting distinct entries in the relocation sections · eda09fbd
      Emil 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: NEmil Medve <Emilian.Medve@Freescale.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      eda09fbd
  17. 11 12月, 2006 1 次提交
    • J
      [POWERPC] Generic BUG for powerpc · 73c9ceab
      Jeremy 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: NJeremy 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: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      73c9ceab
  18. 25 10月, 2006 1 次提交
  19. 28 4月, 2006 1 次提交
    • A
      [PATCH] powerpc64: Fix loading of modules without a .toc section · f749edae
      Alan 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: NPaul Mackerras <paulus@samba.org>
      f749edae
  20. 14 11月, 2005 1 次提交
  21. 12 10月, 2005 1 次提交
  22. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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!
      1da177e4