litmus-rt.git/arch/powerpc/Makefile, branch wip-default-clustering

powerpc: Fix typo in uImage target

2010-08-24T05:26:32+00:00

Commit e32e78c5ee8aadef020fbaecbe6fb741ed9029fd
(powerpc: fix build with make 3.82) introduced a
typo in uImage target and broke building uImage:

make: *** No rule to make target `uImage'.  Stop.

Signed-off-by: Anatolij Gustschin 
Cc: stable 
Signed-off-by: Benjamin Herrenschmidt

powerpc: fix build with make 3.82

2010-08-09T04:14:05+00:00

Thomas Backlund reported that the powerpc build broke with make 3.82.
It failed with the following message:

    arch/powerpc/Makefile:183: *** mixed implicit and normal rules.  Stop.

The fix is to avoid mixing non-wildcard and wildcard targets.

Reported-by: Thomas Backlund 
Tested-by: Thomas Backlund 
Cc: Michal Marek 
Cc: stable 
Signed-off-by: Sam Ravnborg 
Signed-off-by: Benjamin Herrenschmidt

Merge commit 'v2.6.35' into kbuild/kbuild

2010-08-04T11:59:13+00:00

Conflicts:
	arch/powerpc/Makefile

kbuild: allow assignment to {A,C,LD}FLAGS_MODULE on the command line

2010-08-03T12:09:45+00:00

It is now possible to assign options to AS, CC and LD
on the command line - which is only used when building modules.

{A,C,LD}FLAGS_MODULE was all used both in the top-level Makefile
in the arch makefiles, thus users had no way to specify
additional options to AS, CC, LD when building modules
without overriding the original value.

Introduce a new set of variables KBUILD_{A,C,LD}FLAGS_MODULE
that is used by arch specific files and free up
{A,C,LD}FLAGS_MODULE so they can be assigned on
the command line.

All arch Makefiles that used the old variables has been updated.

Note: Previously we had a MODFLAGS variable for both
AS and CC. But in favour of consistency this was dropped.
So in some cases arch Makefile has one assignmnet replaced by
two assignmnets.

Note2: MODFLAGS was not documented and is dropped
without any notice. I do not expect much/any breakage
from this.

Signed-off-by: Sam Ravnborg 
Cc: Denys Vlasenko 
Cc: Haavard Skinnemoen 
Cc: Mike Frysinger 
Cc: Tony Luck 
Cc: Geert Uytterhoeven 
Cc: Ralf Baechle 
Cc: Benjamin Herrenschmidt 
Cc: Martin Schwidefsky 
Cc: Chen Liqin 
Acked-by: Mike Frysinger  [blackfin]
Acked-by: Haavard Skinnemoen  [avr32]
Signed-off-by: Michal Marek

powerpc: Fix module building for gcc 4.5 and 64 bit

2010-07-08T08:11:38+00:00

Gcc 4.5 is now generating out of line register save and restore
in the function prefix and postfix when we use -Os.

Signed-off-by: Stephen Rothwell 
Signed-off-by: Benjamin Herrenschmidt

kbuild: move -fno-dwarf2-cfi-asm to powerpc only

2010-02-05T22:21:18+00:00

Better dwarf2 unwind information is a good thing, it allows better
debugging with kgdb and crash and helps systemtap.

Commit 003086497f07f7f1e67c0c295e261740f822b377 ("Build with
-fno-dwarf2-cfi-asm") disabled some CFI information globally to work
around a module loader bug on powerpc.

But this disables the better unwind tables for all architectures, not just
powerpc.  Move the workaround to powerpc and also add a suitable comment
that's it really a workaround.

This improves dwarf2 unwind tables on x86 at least.

Signed-off-by: Andi Kleen 
Cc: Kyle McMartin 
Signed-off-by: Andrew Morton 
Acked-by: Benjamin Herrenschmidt 
Signed-off-by: Michal Marek

powerpc: Check for unsupported relocs when using CONFIG_RELOCATABLE

2009-09-24T05:31:40+00:00

When using CONFIG_RELOCATABLE, we build the kernel as a position
independent executable. The kernel then uses a little bit of relocation
code to relocate itself. That code only deals with R_PPC64_RELATIVE
relocations though. If for some reason you use assembly constructs
such as LOAD_REG_IMMEDIATE() to load the address of a symbol, you'll
generate different kinds of relocations that won't be processed properly
and bad things will happen. (We have 2 such bugs today).

The perl script tries to filter out "known" bad ones. It's possible
that we are missing some in the case of a weak function that nobody
implements, we'll see if we get false positive and fix it.

Signed-off-by: Tony Breeds 
Signed-off-by: Benjamin Herrenschmidt

arm, cris, mips, sparc, powerpc, um, xtensa: fix build with bash 4.0

2009-09-20T10:28:22+00:00

Albin Tonnerre  reported:

    Bash 4 filters out variables which contain a dot in them.
    This happends to be the case of CPPFLAGS_vmlinux.lds.
    This is rather unfortunate, as it now causes
    build failures when using SHELL=/bin/bash to compile,
    or when bash happens to be used by make (eg when it's /bin/sh)

Remove the common definition of CPPFLAGS_vmlinux.lds by
pushing relevant stuff to either Makefile.build or the
arch specific kernel/Makefile where we build the linker script.

This is also nice cleanup as we move the information out where
it is used.

Notes for the different architectures touched:

arm - we use an already exported symbol
cris - we use a config symbol aleady available
       [Not build tested]
mips - the jiffies complexity has moved to vmlinux.lds.S where we need it.
       Added a few variables to CPPFLAGS - they are only used by
       the linker script.
       [Not build tested]
powerpc - removed assignment that is not needed
          [not build tested]
sparc - simplified it using $(BITS)
um - introduced a few new exported variables to deal with this
xtensa - added options to CPP invocation
         [not build tested]

Cc: Albin Tonnerre 
Cc: Russell King 
Cc: Mikael Starvik 
Cc: Jesper Nilsson 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: "David S. Miller" 
Cc: Jeff Dike 
Cc: Chris Zankel 
Signed-off-by: Sam Ravnborg

kbuild: use INSTALLKERNEL to select customized installkernel script

2009-09-20T10:18:14+00:00

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:

  0f8e2d62fa04441cd12c08ce521e84e5bd3f8a46
  ("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: Peter Zijlstra 
Acked-by: Mike Frysinger  [blackfin]
Acked-by: Russell King  [arm]
Acked-by: Paul Mundt  [sh]
Acked-by: "H. Peter Anvin"  [x86]
Cc: Ian Campbell 
Cc: Tony Luck  [ia64]
Cc: Fenghua Yu  [ia64]
Cc: Hirokazu Takata  [m32r]
Cc: Geert Uytterhoeven  [m68k]
Cc: Kyle McMartin  [parisc]
Cc: Benjamin Herrenschmidt  [powerpc]
Cc: Martin Schwidefsky  [s390]
Cc: Thomas Gleixner  [x86]
Cc: Ingo Molnar  [x86]
Signed-off-by: Sam Ravnborg

powerpc: Makefile simplification through use of cc-ifversion

2009-08-20T00:12:33+00:00

Signed-off-by: Frans Pop 
Acked-by: Sam Ravnborg 
Signed-off-by: Benjamin Herrenschmidt