Skip to content
  1. Oct 16, 2012
  2. Oct 03, 2012
    • Jean Delvare's avatar
      kbuild: Fix gcc -x syntax · b1e0d8b7
      Jean Delvare authored
      
      
      The correct syntax for gcc -x is "gcc -x assembler", not
      "gcc -xassembler". Even though the latter happens to work, the former
      is what is documented in the manual page and thus what gcc wrappers
      such as icecream do expect.
      
      This isn't a cosmetic change. The missing space prevents icecream from
      recognizing compilation tasks it can't handle, leading to silent kernel
      miscompilations.
      
      Besides me, credits go to Michael Matz and Dirk Mueller for
      investigating the miscompilation issue and tracking it down to this
      incorrect -x parameter syntax.
      
      Signed-off-by: default avatarJean Delvare <jdelvare@suse.de>
      Acked-by: default avatarIngo Molnar <mingo@kernel.org>
      Cc: stable@vger.kernel.org
      Cc: Bernhard Walle <bernhard@bwalle.de>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
      b1e0d8b7
  3. Sep 27, 2012
  4. Sep 21, 2012
    • Jeff Mahoney's avatar
      x86/kbuild: archscripts depends on scripts_basic · 24cc7fb6
      Jeff Mahoney authored
      
      
      While building the SUSE kernel packages, which build the scripts,
      make clean, and then build everything, we have been running into spurious
      build failures. We tracked them down to a simple dependency issue:
      
      $ make mrproper
        CLEAN   arch/x86/tools
        CLEAN   scripts/basic
      $ cp patches/config/x86_64/desktop .config
      $ make archscripts
        HOSTCC  arch/x86/tools/relocs
      /bin/sh: scripts/basic/fixdep: No such file or directory
      make[3]: *** [arch/x86/tools/relocs] Error 1
      make[2]: *** [archscripts] Error 2
      make[1]: *** [sub-make] Error 2
      make: *** [all] Error 2
      
      This was introduced by commit
      6520fe55 (x86, realmode: 16-bit real-mode code support for relocs),
      which added the archscripts dependency to archprepare.
      
      This patch adds the scripts_basic dependency to the x86 archscripts.
      
      Signed-off-by: default avatarJeff Mahoney <jeffm@suse.com>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
      24cc7fb6
  5. Aug 11, 2012
  6. Jun 24, 2012
  7. May 22, 2012
  8. May 19, 2012
    • H. Peter Anvin's avatar
      x86, realmode: 16-bit real-mode code support for relocs tool · 6520fe55
      H. Peter Anvin authored
      
      
      A new option is added to the relocs tool called '--realmode'.
      This option causes the generation of 16-bit segment relocations
      and 32-bit linear relocations for the real-mode code. When
      the real-mode code is moved to the low-memory during kernel
      initialization, these relocation entries can be used to
      relocate the code properly.
      
      In the assembly code 16-bit segment relocations must be relative
      to the 'real_mode_seg' absolute symbol. Linear relocations must be
      relative to a symbol prefixed with 'pa_'.
      
      16-bit segment relocation is used to load cs:ip in 16-bit code.
      Linear relocations are used in the 32-bit code for relocatable
      data references. They are declared in the linker script of the
      real-mode code.
      
      The relocs tool is moved to arch/x86/tools/relocs.c, and added new
      target archscripts that can be used to build scripts needed building
      an architecture.  be compiled before building the arch/x86 tree.
      
      [ hpa: accelerating this because it detects invalid absolute
        relocations, a serious bug in binutils 2.22.52.0.x which currently
        produces bad kernels. ]
      
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      Link: http://lkml.kernel.org/r/1336501366-28617-2-git-send-email-jarkko.sakkinen@intel.com
      
      
      Signed-off-by: default avatarJarkko Sakkinen <jarkko.sakkinen@intel.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      Cc: <stable@vger.kernel.org>
      6520fe55
  9. May 09, 2012
  10. May 05, 2012
  11. Mar 31, 2012
  12. Feb 28, 2012
  13. Nov 18, 2011
    • H. Peter Anvin's avatar
      x86: Generate system call tables and unistd_*.h from tables · 303395ac
      H. Peter Anvin authored
      
      
      Generate system call tables and unistd_*.h automatically from the
      tables in arch/x86/syscalls.  All other information, like NR_syscalls,
      is auto-generated, some of which is in asm-offsets_*.c.
      
      This allows us to keep all the system call information in one place,
      and allows for kernel space and user space to see different
      information; this is currently used for the ia32 system call numbers
      when building the 64-bit kernel, but will be used by the x32 ABI in
      the near future.
      
      This also removes some gratuitious differences between i386, x86-64
      and ia32; in particular, now all system call tables are generated with
      the same mechanism.
      
      Cc: H. J. Lu <hjl.tools@gmail.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Cc: Michal Marek <mmarek@suse.cz>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      303395ac
  14. Oct 14, 2010
  15. Sep 14, 2010
  16. May 14, 2010
  17. Feb 17, 2010
  18. Oct 23, 2009
  19. Sep 20, 2009
    • Sam Ravnborg's avatar
      kbuild: use INSTALLKERNEL to select customized installkernel script · caa27b66
      Sam Ravnborg authored
      
      
      Replace the use of CROSS_COMPILE to select a customized
      installkernel script with the possibility to set INSTALLKERNEL
      to select a custom installkernel script when running make:
      
          make INSTALLKERNEL=arm-installkernel install
      
      With this patch we are now more consistent across
      different architectures - they did not all support use
      of CROSS_COMPILE.
      
      The use of CROSS_COMPILE was a hack as this really belongs
      to gcc/binutils and the installkernel script does not change
      just because we change toolchain.
      
      The use of CROSS_COMPILE caused troubles with an upcoming patch
      that saves CROSS_COMPILE when a kernel is built - it would no
      longer be installable.
      [Thanks to Peter Z. for this hint]
      
      This patch undos what Ian did in commit:
      
        0f8e2d62
        ("use ${CROSS_COMPILE}installkernel in arch/*/boot/install.sh")
      
      The patch has been lightly tested on x86 only - but all changes
      looks obvious.
      
      Acked-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Acked-by: Mike Frysinger <vapier@gentoo.org> [blackfin]
      Acked-by: Russell King <linux@arm.linux.org.uk> [arm]
      Acked-by: Paul Mundt <lethal@linux-sh.org> [sh]
      Acked-by: "H. Peter Anvin" <hpa@zytor.com> [x86]
      Cc: Ian Campbell <icampbell@arcom.com>
      Cc: Tony Luck <tony.luck@intel.com> [ia64]
      Cc: Fenghua Yu <fenghua.yu@intel.com> [ia64]
      Cc: Hirokazu Takata <takata@linux-m32r.org> [m32r]
      Cc: Geert Uytterhoeven <geert@linux-m68k.org> [m68k]
      Cc: Kyle McMartin <kyle@mcmartin.ca> [parisc]
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> [powerpc]
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> [s390]
      Cc: Thomas Gleixner <tglx@linutronix.de> [x86]
      Cc: Ingo Molnar <mingo@redhat.com> [x86]
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      caa27b66
  20. Aug 31, 2009
  21. Aug 27, 2009
    • Masami Hiramatsu's avatar
      x86: X86 instruction decoder build-time selftest · ca0e9bad
      Masami Hiramatsu authored
      
      
      Add a user-space selftest of x86 instruction decoder at kernel build
      time.
      When CONFIG_X86_DECODER_SELFTEST=y, Kbuild builds a test harness of x86
      instruction decoder and performs it after building vmlinux.
      The test compares the results of objdump and x86 instruction decoder
      code and check there are no differences.
      
      Signed-off-by: default avatarMasami Hiramatsu <mhiramat@redhat.com>
      Signed-off-by: default avatarJim Keniston <jkenisto@us.ibm.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Avi Kivity <avi@redhat.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Frank Ch. Eigler <fche@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: K.Prasad <prasad@linux.vnet.ibm.com>
      Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
      Cc: Li Zefan <lizf@cn.fujitsu.com>
      Cc: Przemysław Pawełczyk <przemyslaw@pawelczyk.it>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      Cc: Vegard Nossum <vegard.nossum@gmail.com>
      LKML-Reference: <20090813203421.31965.29006.stgit@localhost.localdomain>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      ca0e9bad
  22. Aug 23, 2009
  23. Aug 04, 2009
  24. Jun 13, 2009
  25. Apr 18, 2009
    • H. Peter Anvin's avatar
      x86, kbuild: make "make install" not depend on vmlinux · 1648e4f8
      H. Peter Anvin authored
      
      
      It is common to use "make install" in restricted environments which
      differ from the one which was actually used to build the kernel.  In
      such environments it is highly undesirable to trigger a rebuild of any
      part of the system.  Worse, the rebuild may be spurious, triggered by
      differences in the environment.
      
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      LKML-Reference: <20090415234642.GA28531@uranus.ravnborg.org>
      1648e4f8
  26. Apr 17, 2009
  27. Mar 13, 2009
  28. Feb 10, 2009
    • Tejun Heo's avatar
      stackprotector: update make rules · 5d707e9c
      Tejun Heo authored
      
      
      Impact: no default -fno-stack-protector if stackp is enabled, cleanup
      
      Stackprotector make rules had the following problems.
      
      * cc support test and warning are scattered across makefile and
        kernel/panic.c.
      
      * -fno-stack-protector was always added regardless of configuration.
      
      Update such that cc support test and warning are contained in makefile
      and -fno-stack-protector is added iff stackp is turned off.  While at
      it, prepare for 32bit support.
      
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      5d707e9c
  29. Jan 29, 2009
  30. Oct 23, 2008
  31. Jul 26, 2008
  32. Jul 11, 2008
  33. Jun 10, 2008
  34. Jun 05, 2008
  35. May 26, 2008