While changing our build system over to use the headers_install target
as part of our klibc build, the following message started showing up in
our logs:

make[2]: `scripts/unifdef' is up to date.

It turns out that the build blindly invokes a recursive make on this
target, which causes make to emit this message when the target is
already up to date.  This isn't seen for most targets as the rest of the
build relies primarily on the default target and on PHONY targets when
invoking make recursively.

Silence the above message when building unifdef as part of
headers_install by hiding it behind a new PHONY target called
"build_unifdef" that has an empty recipe.
Signed-off-by: NMike Waychison <mikew@google.com>
Acked-by: NWANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

Add a 'W=1' Makefile switch which adds additional checking per build
object.

The idea behind this option is targeted at developers who, in the
process of writing their code, want to do the occasional

make W=1 [target.o]

and let gcc do more extensive code checking for them. Then, they
could eyeball the output for valid gcc warnings about various
bugs/discrepancies which are not reported during the normal build
process.

For more background information and a use case, read through this
thread: http://marc.info/?l=kernel-janitors&m=129802065918147&w=2

Cc: Michal Marek <mmarek@suse.cz>
Cc: linux-kbuild@vger.kernel.org
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Acked-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NBorislav Petkov <bp@alien8.de>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

Signed-off-by: NGilles Espinasse <g.esp@free.fr>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

GNU GLOBAL (http://www.gnu.org/software/global/) is a source code tagging system
It is really cheap to support it in kbuild system.
Signed-off-by: NJianbin Kang <kjbmail@gmail.com>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

If you try to build a kernel with KCONFIG_CONFIG set (to a value
not equal to .config) and that config sets CONFIG_IKCONFIG then the
build will fail with:

make[1]: *** No rule to make target `.config', needed by \
`kernel/config_data.gz'.  Stop.

because the kernel/Makefile contains a direct reference to .config.

This issue has been present since the introduction of KCONFIG_CONFIG
in 14cdd3c4.
Signed-off-by: NBen Gardiner <bengardiner@nanometrics.ca>
CC: Roman Zippel <zippel@linux-m68k.org>
CC: Michal Marek <mmarek@suse.cz>
Reviewed-by: NMichal Marek <mmarek@suse.cz>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

Add 'sparc32' ARCH target to test all{yes,mod}config for 32-bit build.
Signed-off-by: NNamhyung Kim <namhyung@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The config option used by archs to let the build system know that
the C version of the recordmcount works for said arch is currently
called HAVE_C_MCOUNT_RECORD which enables BUILD_C_RECORDMCOUNT. To
be more consistent with the name that all archs may use, it has been
renamed to HAVE_C_RECORDMCOUNT. This will be less confusing since
we are building a C recordmcount and not a mcount_record.
Suggested-by: NIngo Molnar <mingo@elte.hu>
Cc: <linux-arch@vger.kernel.org>
Cc: Michal Marek <mmarek@suse.cz>
Cc: linux-kbuild@vger.kernel.org
Cc: John Reiser <jreiser@bitwagon.com>
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>

This patch adds the support for the C version of recordmcount and
compile times show ~ 12% improvement.

After verifying this works, other archs can add:

 HAVE_C_MCOUNT_RECORD

in its Kconfig and it will use the C version of recordmcount
instead of the perl version.

Cc: <linux-arch@vger.kernel.org>
Cc: Michal Marek <mmarek@suse.cz>
Cc: linux-kbuild@vger.kernel.org
Cc: John Reiser <jreiser@bitwagon.com>
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>

base patch to implement 'jump labeling'. Based on a new 'asm goto' inline
assembly gcc mechanism, we can now branch to labels from an 'asm goto'
statment. This allows us to create a 'no-op' fastpath, which can subsequently
be patched with a jump to the slowpath code. This is useful for code which
might be rarely used, but which we'd like to be able to call, if needed.
Tracepoints are the current usecase that these are being implemented for.
Acked-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NJason Baron <jbaron@redhat.com>
LKML-Reference: <ee8b3595967989fdaf84e698dc7447d315ce972a.1284733808.git.jbaron@redhat.com>

[ cleaned up some formating ]
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>

The list of patterns for the external modules case was constantly
lagging behind.
Signed-off-by: NMichal Marek <mmarek@suse.cz>

Signed-off-by: NMichal Marek <mmarek@suse.cz>

With current gcc, compiling with both -pg and -fomit-frame-pointer is
not allowed.  However, -pg can be used to build without actually
specifying -fno-omit-frame-pointer, upon which the default behaviour
for the target will be used.

On ARM, it is not possible to build a Thumb-2 kernel with
-fno-omit-frame-pointer (FRAME_POINTERS depends on !THUMB2_KERNEL). In
order to support ftrace for Thumb-2, we need to be able to allow a
combination of FUNCTION_TRACER and !FRAME_POINTER.  We do this by
omitting -fomit-frame-pointer if ftrace is enabled.
Acked-by: NFrederic Weisbecker <fweisbec@gmail.com>
Signed-off-by: NRabin Vincent <rabin@rab.in>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Brice reported that 'kernelrelease' has a dependence on include/config/kernel.release,
causes this file to be regenerated every time when invoke it. It doesn't have to.
Reported-by: NBrice Goglin <Brice.Goglin@inria.fr>
Tested-by: NBrice Goglin <Brice.Goglin@inria.fr>
Signed-off-by: NWANG Cong <amwang@redhat.com>
Signed-off-by: NMichal Marek <mmarek@suse.cz>