1. 28 11月, 2009 1 次提交
  2. 20 11月, 2009 1 次提交
    • T
      x86: Prevent GCC 4.4.x (pentium-mmx et al) function prologue wreckage · 746357d6
      Thomas Gleixner 提交于
      When the kernel is compiled with -pg for tracing GCC 4.4.x inserts
      stack alignment of a function _before_ the mcount prologue if the
      -march=pentium-mmx is set and -mtune=generic is not set. This breaks
      the assumption of the function graph tracer which expects that the
      mcount prologue
      
             push %ebp
             mov  %esp, %ebp
      
      is the first stack operation in a function because it needs to modify
      the function return address on the stack to trap into the tracer
      before returning to the real caller.
      
      The generated code is:
      
              push   %edi
              lea    0x8(%esp),%edi
              and    $0xfffffff0,%esp
              pushl  -0x4(%edi)
              push   %ebp
              mov    %esp,%ebp
      
      so the tracer modifies the copy of the return address which is stored
      after the stack alignment and therefor does not trap the return which
      in turn breaks the call chain logic of the tracer and leads to a
      kernel panic.
      
      Aside of the fact that the generated code is horrible for no good
      reason other -march -mtune options generate the expected:
      
              push   %ebp
              mov    %esp,%ebp
              and    $0xfffffff0,%esp
      
      which does the same and keeps everything intact.
      
      After some experimenting we found out that this problem is restricted
      to gcc4.4.x and to the following -march settings:
      
      i586, pentium, pentium-mmx, k6, k6-2, k6-3, winchip-c6, winchip2, c3,
      geode
      
      By adding -mtune=generic the code generator produces always the
      expected code.
      
      So forcing -mtune=generic when CONFIG_FUNCTION_GRAPH_TRACER=y is not
      pretty, but at the moment the only way to prevent that the kernel
      trips over gcc-shrooms induced code madness.
      
      Most distro kernels have CONFIG_X86_GENERIC=y anyway which forces
      -mtune=generic as well so it will not impact those.
      
      References: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109
      	    http://lkml.org/lkml/2009/11/19/17Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      LKML-Reference: <alpine.LFD.2.00.0911200206570.24119@localhost.localdomain>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>,
      Cc: Jeff Law <law@redhat.com>
      Cc: gcc@gcc.gnu.org
      Cc: David Daney <ddaney@caviumnetworks.com>
      Cc: Andrew Haley <aph@redhat.com>
      Cc: Richard Guenther <richard.guenther@gmail.com>
      Cc: stable@kernel.org
      746357d6
  3. 23 8月, 2009 1 次提交
  4. 13 10月, 2008 1 次提交
  5. 10 9月, 2008 1 次提交
    • H
      x86: prevent binutils from being "smart" and generating NOPLs for us · 28f7e66f
      H. Peter Anvin 提交于
      binutils, contrary to documented behaviour, will generate long NOPs (a
      P6-or-higher instruction which is broken on at least some VIA chips,
      Virtual PC/Virtual Server, and some versions of Qemu) depending on the
      -mtune= option, which is not supposed to change architectural
      behaviour.
      
      Pass an explicit override to the assembler, in case ends up passing
      the -mtune= parameter to gas (gcc 4.3.0 does not appear to.)
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      28f7e66f
  6. 26 10月, 2007 1 次提交
  7. 03 5月, 2007 2 次提交
  8. 07 12月, 2006 1 次提交
  9. 26 3月, 2006 1 次提交
  10. 09 1月, 2006 1 次提交
  11. 31 10月, 2005 2 次提交
    • P
      [PATCH] i386: use -mcpu, not -mtune, for GCCs older than 3.4 · d89ea9b8
      Paolo 'Blaisorblade' Giarrusso 提交于
      I just noted that -mtune is used, which is only supported on recent GCCs; by
      reading http://gcc.gnu.org/gcc-3.4/changes.html, you see "-mcpu has been
      renamed to -mtune.", so for GCC < 3.4 we're not using any specific tuning in
      the appropriate cases.  However -mcpu is deprecated, so use -mtune when
      possible.
      
      This was introduced by commit e9d4dce954a60dc23dd1d967766ca2347b780e54 of the
      old tree (between 2.6.10-rc3 and 2.6.10) by Linus Torvalds, to remove the use
      of -march, since that could trigger gcc using SSE on its own.  But no
      attention was used about using -mcpu vs.  -mtune.
      
      And btw, the old 2.6.4 code (for instance) was:
      cflags-$(CONFIG_MPENTIUMII)     += $(call check_gcc,-march=pentium2,-march=i686)
      cflags-$(CONFIG_MPENTIUMIII)    += $(call check_gcc,-march=pentium3,-march=i686)
      cflags-$(CONFIG_MPENTIUMM)      += $(call check_gcc,-march=pentium3,-march=i686)
      cflags-$(CONFIG_MPENTIUM4)      += $(call check_gcc,-march=pentium4,-march=i686)
      Signed-off-by: NPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d89ea9b8
    • P
      [PATCH] uml: reuse i386 cpu-specific tuning · 96d55b88
      Paolo 'Blaisorblade' Giarrusso 提交于
      Make UML share the underlying cpu-specific tuning done on i386.
      
      Actually, for now many config options aren't used a lot - but that can be done
      later.  Also, UML relies on GCC optimization for things like memcpy and such
      more than i386, so specifying the correct -march and -mtune should be enough.
      Later, we may want to correct some other stuff.
      
      For instance, since FPU context switching, for us, is done (at least
      partially, i.e.  between our kernelspace and userspace) by the host, we may
      allow usage of FPU operations by GCC.  This doesn't hold for kernelspace vs.
      kernelspace, but we don't support preemption.
      Signed-off-by: NPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      96d55b88