1. 11 3月, 2011 1 次提交
    • D
      ARM: 6781/1: Thumb-2: Work around buggy Thumb-2 short branch relocations in gas · 6f685c5c
      Dave Martin 提交于
      Various binutils versions can resolve Thumb-2 branches to
      locally-defined, preemptible global symbols as short-range "b.n"
      branch instructions.
      
      This is a problem, because there's no guarantee the final
      destination of the symbol, or any candidate locations for a
      trampoline, are within range of the branch.  For this reason, the
      kernel does not support fixing up the R_ARM_THM_JUMP11 (102)
      relocation in modules at all, and it makes little sense to add
      support.
      
      The symptom is that the kernel fails with an "unsupported
      relocation" error when loading some modules.
      
      Until fixed tools are available, passing
      -fno-optimize-sibling-calls to gcc should prevent gcc generating
      code which hits this problem, at the cost of a bit of extra runtime
      stack usage in some cases.
      
      The problem is described in more detail at:
          https://bugs.launchpad.net/binutils-linaro/+bug/725126
      
      Only Thumb-2 kernels are affected.
      
      This patch adds a new CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11 config
      option which adds -fno-optimize-sibling-calls to CFLAGS_MODULE
      when building a Thumb-2 kernel.
      Signed-off-by: NDave Martin <dave.martin@linaro.org>
      Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      6f685c5c
  2. 10 3月, 2011 2 次提交
  3. 09 3月, 2011 5 次提交
  4. 26 2月, 2011 1 次提交
    • N
      ARM: 6746/1: remove the 4x expansion presumption while decompressing the kernel · d239b1dc
      Nicolas Pitre 提交于
      We currently presume a 4x expansion to guess the decompressed kernel size
      in order to determine if the decompressed kernel is in conflict with
      the location where zImage is loaded.  This guess may cause many issues
      by overestimating the final kernel image size:
      
      - This may force a needless relocation if the location of zImage was
        fine, wasting some precious microseconds of boot time.
      
      - The relocation may be located way too far, possibly overwriting the
        initrd image in RAM.
      
      - If the kernel image includes a large already-compressed initramfs image
        then the problem is even more exacerbated.
      
      And if by some strange means the 4x guess is too low then we may overwrite
      ourselves with the decompressed image.
      
      So let's use the exact decompressed kernel image size instead.  For that
      we need to rely on the stat command, but this is hardly a new build
      dependency as the kernel already depends on many external commands
      to be built provided by the coreutils package where stat is found.
      Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      d239b1dc
  5. 24 2月, 2011 14 次提交
  6. 16 2月, 2011 1 次提交
  7. 01 2月, 2011 11 次提交
  8. 31 1月, 2011 5 次提交