kbuild: fix linker feature test macros when cross compiling with Clang

I was not seeing my linker flags getting added when using ld-option when
cross compiling with Clang. Upon investigation, this s

kbuild: fix linker feature test macros when cross compiling with Clang

I was not seeing my linker flags getting added when using ld-option when
cross compiling with Clang. Upon investigation, this seems to be due to
a difference in how GCC vs Clang handle cross compilation.

GCC is configured at build time to support one backend, that is implicit
when compiling. Clang is explicit via the use of `-target <triple>` and
ships with all supported backends by default.

GNU Make feature test macros that compile then link will always fail
when cross compiling with Clang unless Clang's triple is passed along to
the compiler. For example:

$ clang -x c /dev/null -c -o temp.o
$ aarch64-linux-android/bin/ld -E temp.o
aarch64-linux-android/bin/ld:
unknown architecture of input file `temp.o' is incompatible with
aarch64 output
aarch64-linux-android/bin/ld:
warning: cannot find entry symbol _start; defaulting to
0000000000400078
$ echo $?
1

$ clang -target aarch64-linux-android- -x c /dev/null -c -o temp.o
$ aarch64-linux-android/bin/ld -E temp.o
aarch64-linux-android/bin/ld:
warning: cannot find entry symbol _start; defaulting to 00000000004002e4
$ echo $?
0

This causes conditional checks that invoke $(CC) without the target
triple, then $(LD) on the result, to always fail.

Suggested-by: Masahiro Yamada <[email protected]>
Signed-off-by: Nick Desaulniers <[email protected]>
Reviewed-by: Matthias Kaehlcke <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kbuild: shrink .cache.mk when it exceeds 1000 lines

The cache files are only cleaned away by "make clean". If you continue
incremental builds, the cache files will grow up little by little.
It is n

kbuild: shrink .cache.mk when it exceeds 1000 lines

The cache files are only cleaned away by "make clean". If you continue
incremental builds, the cache files will grow up little by little.
It is not a big deal in general use cases because compiler flags do not
change quite often.

However, if you do build-test for various architectures, compilers, and
kernel configurations, you will end up with huge cache files soon.

When the cache file exceeds 1000 lines, shrink it down to 500 by "tail".
The Least Recently Added lines are cut. (not Least Recently Used)
I hope it will work well enough.

Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>

show more ...

kbuild: Add a cache for generated variables

While timing a "no-op" build of the kernel (incrementally building the
kernel even though nothing changed) in the Chrome OS build system I
found that it w

kbuild: Add a cache for generated variables

While timing a "no-op" build of the kernel (incrementally building the
kernel even though nothing changed) in the Chrome OS build system I
found that it was much slower than I expected.

Digging into things a bit, I found that quite a bit of the time was
spent invoking the C compiler even though we weren't actually building
anything. Currently in the Chrome OS build system the C compiler is
called through a number of wrappers (one of which is written in
python!) and can take upwards of 100 ms to invoke even if we're not
doing anything difficult, so these invocations of the compiler were
taking a lot of time. Worse the invocations couldn't seem to take
advantage of the multiple cores on my system.

Certainly it seems like we could make the compiler invocations in the
Chrome OS build system faster, but only to a point. Inherently
invoking a program as big as a C compiler is a fairly heavy
operation. Thus even if we can speed the compiler calls it made sense
to track down what was happening.

It turned out that all the compiler invocations were coming from
usages like this in the kernel's Makefile:

KBUILD_CFLAGS += $(call cc-option,-fno-delete-null-pointer-checks,)

Due to the way cc-option and similar statements work the above
contains an implicit call to the C compiler. ...and due to the fact
that we're storing the result in KBUILD_CFLAGS, a simply expanded
variable, the call will happen every time the Makefile is parsed, even
if there are no users of KBUILD_CFLAGS.

Rather than redoing this computation every time, it makes a lot of
sense to cache the result of all of the Makefile's compiler calls just
like we do when we compile a ".c" file to a ".o" file. Conceptually
this is quite a simple idea. ...and since the calls to invoke the
compiler and similar tools are centrally located in the Kbuild.include
file this doesn't even need to be super invasive.

Implementing the cache in a simple-to-use and efficient way is not
quite as simple as it first sounds, though. To get maximum speed we
really want the cache in a format that make can natively understand
and make doesn't really have an ability to load/parse files. ...but
make _can_ import other Makefiles, so the solution is to store the
cache in Makefile format. This requires coming up with a valid/unique
Makefile variable name for each value to be cached, but that's
solvable with some cleverness.

After this change, we'll automatically create a ".cache.mk" file that
will contain our cached variables. We'll load this on each invocation
of make and will avoid recomputing anything that's already in our
cache. The cache is stored in a format that it shouldn't need any
invalidation since anything that might change should affect the "key"
and any old cached value won't be used.

Signed-off-by: Douglas Anderson <[email protected]>
Tested-by: Ingo Molnar <[email protected]>
Tested-by: Guenter Roeck <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kbuild: trivial cleanups on the comments

This is a bunch of trivial fixes and cleanups.

Signed-off-by: Cao jin <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]

kbuild: trivial cleanups on the comments

This is a bunch of trivial fixes and cleanups.

Signed-off-by: Cao jin <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kbuild: Add __cc-option macro

cc-option uses KBUILD_CFLAGS and KBUILD_CPPFLAGS when it determines
whether an option is supported or not. This is fine for options used to
build the kernel itself, how

kbuild: Add __cc-option macro

cc-option uses KBUILD_CFLAGS and KBUILD_CPPFLAGS when it determines
whether an option is supported or not. This is fine for options used to
build the kernel itself, however some components like the x86 boot code
use a different set of flags.

Add the new macro __cc-option which is a more generic version of
cc-option with additional parameters. One parameter is the compiler
with which the check should be performed, the other the compiler options
to be used instead KBUILD_C*FLAGS.

Refactor cc-option and hostcc-option to use __cc-option and move
hostcc-option to scripts/Kbuild.include.

Suggested-by: Arnd Bergmann <[email protected]>
Suggested-by: Masahiro Yamada <[email protected]>
Signed-off-by: Matthias Kaehlcke <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Acked-by: Michal Marek <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kbuild: remove cc-option-align

Documentation/kbuild/makefiles.txt says the change for align options
occurred at GCC 3.0, and Documentation/process/changes.rst says the
minimal supported GCC version

kbuild: remove cc-option-align

Documentation/kbuild/makefiles.txt says the change for align options
occurred at GCC 3.0, and Documentation/process/changes.rst says the
minimal supported GCC version is 3.2, so it should be safe to hard-code
-falign* options.

Fix the only user arch/x86/Makefile_32.cpu and remove cc-option-align.

Signed-off-by: Masahiro Yamada <[email protected]>
Acked-by: Ingo Molnar <[email protected]>

show more ...

kbuild, LLVMLinux: Add -Werror to cc-option to support clang

Clang will warn about unknown warnings but will not return false
unless -Werror is set. GCC will return false if an unknown
warning is pa

kbuild, LLVMLinux: Add -Werror to cc-option to support clang

Clang will warn about unknown warnings but will not return false
unless -Werror is set. GCC will return false if an unknown
warning is passed.

Adding -Werror make both compiler behave the same.

[arnd: it turns out we need the same patch for testing whether -ffunction-sections
works right with gcc. I've build tested extensively with this patch
applied, so let's just merge this one now.]

Signed-off-by: Mark Charlebois <[email protected]>
Signed-off-by: Behan Webster <[email protected]>
Reviewed-by: Jan-Simon Möller <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
Acked-by: Kees Cook <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

x86/build: Mostly disable '-maccumulate-outgoing-args'

The GCC '-maccumulate-outgoing-args' flag is enabled for most configs,
mostly because of issues which are no longer relevant. For most
configs

x86/build: Mostly disable '-maccumulate-outgoing-args'

The GCC '-maccumulate-outgoing-args' flag is enabled for most configs,
mostly because of issues which are no longer relevant. For most
configs, and with most recent versions of GCC, it's no longer needed.

Clarify which cases need it, and only enable it for those cases. Also
produce a compile-time error for the ftrace graph + mcount + '-Os' case,
which will otherwise cause runtime failures.

The main benefit of '-maccumulate-outgoing-args' is that it prevents an
ugly prologue for functions which have aligned stacks. But removing the
option also has some benefits: more readable argument saves, smaller
text size, and (presumably) slightly improved performance.

Here are the object size savings for 32-bit and 64-bit defconfig
kernels:

text data bss dec hex filename
10006710 3543328 1773568 15323606 e9d1d6 vmlinux.x86-32.before
9706358 3547424 1773568 15027350 e54c96 vmlinux.x86-32.after

text data bss dec hex filename
10652105 4537576 843776 16033457 f4a6b1 vmlinux.x86-64.before
10639629 4537576 843776 16020981 f475f5 vmlinux.x86-64.after

That comes out to a 3% text size improvement on x86-32 and a 0.1% text
size improvement on x86-64.

Signed-off-by: Josh Poimboeuf <[email protected]>
Cc: Andrew Lutomirski <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Brian Gerst <[email protected]>
Cc: Denys Vlasenko <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Pavel Machek <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Steven Rostedt <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Link: http://lkml.kernel.org/r/20170316193133.zrj6gug53766m6nn@treble
Signed-off-by: Ingo Molnar <[email protected]>

show more ...

Kbuild: Add cpp_its_S in ksym_dep_filter

Add a new command cpp_its_S introduced in commit cf2a5e0bb4c6 ("MIPS:
Support generating Flattened Image Trees (.itb)") to ksym_dep_filter
handler - otherwis

Kbuild: Add cpp_its_S in ksym_dep_filter

Add a new command cpp_its_S introduced in commit cf2a5e0bb4c6 ("MIPS:
Support generating Flattened Image Trees (.itb)") to ksym_dep_filter
handler - otherwise a warning is produced during the build of MIPS
platforms (when vmlinux.*.itb target is chosen).

Signed-off-by: Marcin Nowakowski <[email protected]>
Cc: Michal Marek <[email protected]>
Cc: [email protected]
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/15278/
Signed-off-by: James Hogan <[email protected]>

show more ...

kbuild: no gcc-plugins during cc-option tests

The gcc-plugins arguments should not be included when performing
cc-option tests.

Steps to reproduce:
1) make mrproper
2) make defconfig
3) enable GCC_

kbuild: no gcc-plugins during cc-option tests

The gcc-plugins arguments should not be included when performing
cc-option tests.

Steps to reproduce:
1) make mrproper
2) make defconfig
3) enable GCC_PLUGINS, GCC_PLUGIN_CYC_COMPLEXITY
4) enable FUNCTION_TRACER (it will select other options as well)
5) make && make modules

Build errors:
MODPOST 18 modules
ERROR: "__fentry__" [net/netfilter/xt_nat.ko] undefined!
ERROR: "__fentry__" [net/netfilter/xt_mark.ko] undefined!
ERROR: "__fentry__" [net/netfilter/xt_addrtype.ko] undefined!
ERROR: "__fentry__" [net/netfilter/xt_LOG.ko] undefined!
ERROR: "__fentry__" [net/netfilter/nf_nat_sip.ko] undefined!
ERROR: "__fentry__" [net/netfilter/nf_nat_irc.ko] undefined!
ERROR: "__fentry__" [net/netfilter/nf_nat_ftp.ko] undefined!
ERROR: "__fentry__" [net/netfilter/nf_nat.ko] undefined!

Reported-by: Laura Abbott <[email protected]>
Signed-off-by: Emese Revfy <[email protected]>
[kees: renamed variable, clarified commit message]
Signed-off-by: Kees Cook <[email protected]>

show more ...

Kbuild: don't add obj tree in additional includes

When building with separate object directories and driver specific
Makefiles that add additional header include paths, Kbuild adjusts
the gcc flags

Kbuild: don't add obj tree in additional includes

When building with separate object directories and driver specific
Makefiles that add additional header include paths, Kbuild adjusts
the gcc flags so that we include both the directory in the source
tree and in the object tree.

However, due to another bug I fixed earlier, this did not actually
include the correct directory in the object tree, so we know that
we only really need the source tree here. Also, including the
object tree sometimes causes warnings about nonexisting directories
when the include path only exists in the source.

This changes the logic to only emit the -I argument for the srctree,
not for objects. We still need both $(srctree)/$(src) and $(obj)
though, so I'm adding them manually.

Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Michal Marek <[email protected]>

show more ...

Kbuild: don't add ../../ to include path

When we build with O=objdir and objdir is directly below the source tree,
$(srctree) becomes '..'.

When a Makefile adds a CFLAGS option like -Ipath/to/heade

Kbuild: don't add ../../ to include path

When we build with O=objdir and objdir is directly below the source tree,
$(srctree) becomes '..'.

When a Makefile adds a CFLAGS option like -Ipath/to/headers and
we are building with a separate object directory, Kbuild tries to
add two -I options, one for the source tree and one for the object
tree. An absolute path is treated as a special case, and don't add
this one twice. This also normally catches -I$(srctree)/$(src)
as $(srctree) usually is an absolute directory like /home/arnd/linux/.

The combination of the two behaviors however results in an invalid
path name to be included: we get both ../$(src) and ../../$(src),
the latter one pointing outside of the source tree, usually to a
nonexisting directory. Building with 'make W=1' makes this obvious:

cc1: error: ../../arch/arm/mach-s3c24xx/include: No such file or directory [-Werror=missing-include-dirs]

This adds another special case, treating path names starting with ../
like those starting with / so we don't try to prefix that with
$(srctree).

Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Michal Marek <[email protected]>

show more ...

kbuild: fix if_change and friends to consider argument order

Currently, arg-check is implemented as follows:

arg-check = $(strip $(filter-out $(cmd_$(1)), $(cmd_$@)) \
$(fil

kbuild: fix if_change and friends to consider argument order

Currently, arg-check is implemented as follows:

arg-check = $(strip $(filter-out $(cmd_$(1)), $(cmd_$@)) \
$(filter-out $(cmd_$@), $(cmd_$(1))) )

This does not care about the order of arguments that appear in
$(cmd_$(1)) and $(cmd_$@). So, if_changed and friends never rebuild
the target if only the argument order is changed. This is a problem
when the link order is changed.

Apparently,

obj-y += foo.o
obj-y += bar.o

and

obj-y += bar.o
obj-y += foo.o

should be distinguished because the link order determines the probe
order of drivers. So, built-in.o should be rebuilt when the order
of objects is changed.

This commit fixes arg-check to compare the old/current commands
including the argument order.

Of course, this change has a side effect; Kbuild will react to the
change of compile option order. For example, "-DFOO -DBAR" and
"-DBAR -DFOO" should give no difference to the build result, but
false positive should be better than false negative.

I am moving space_escape to the top of Kbuild.include just for a
matter of preference. In practical terms, space_escape can be
defined after arg-check because arg-check uses "=" flavor, not ":=".
Having said that, collecting convenient variables in one place makes
sense from the point of readability.

Chaining "%%%SPACE%%%" to "_-_SPACE_-_" is also a matter of taste
at this point. Actually, it can be arbitrary as long as it is an
unlikely used string. The only problem I see in "%%%SPACE%%%" is
that "%" is a special character in "$(patsubst ...)" context. This
commit just uses "$(subst ...)" for arg-check, but I am fixing it now
in case we might want to use it in $(patsubst ...) context in the
future.

Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Michal Marek <[email protected]>

show more ...

kbuild: fix ksym_dep_filter when multiple EXPORT_SYMBOL() on the same line

In kernel/cgroup.c there is:

#define SUBSYS(_x) \
DEFINE_STATIC_KE

kbuild: fix ksym_dep_filter when multiple EXPORT_SYMBOL() on the same line

In kernel/cgroup.c there is:

#define SUBSYS(_x) \
DEFINE_STATIC_KEY_TRUE(_x ## _cgrp_subsys_enabled_key); \
DEFINE_STATIC_KEY_TRUE(_x ## _cgrp_subsys_on_dfl_key); \
EXPORT_SYMBOL_GPL(_x ## _cgrp_subsys_enabled_key); \
EXPORT_SYMBOL_GPL(_x ## _cgrp_subsys_on_dfl_key);

The expansion of this macro causes multiple EXPORT_SYMBOL_GPL() instances
to appear on the same preprocessor line output, confusing the sed script
expecting only one of them per line. Unfortunately this can't be fixed
nicely in the sed script as sed's regexp can't do non greedy matching.

Fix this by turning any semicolon into a line break before filtering.

Reported-by: Arnd Bergmann <[email protected]>
Signed-off-by: Nicolas Pitre <[email protected]>
Signed-off-by: Michal Marek <[email protected]>

show more ...

kbuild: adjust ksym_dep_filter for some cmd_* renames

The following renames occurred recently:

cmd_cc_i_c --> cmd_cpp_i_c
cmd_as_s_S --> cmd_cpp_s_S

The respective cc_*_c and as_*_S patterns n

kbuild: adjust ksym_dep_filter for some cmd_* renames

The following renames occurred recently:

cmd_cc_i_c --> cmd_cpp_i_c
cmd_as_s_S --> cmd_cpp_s_S

The respective cc_*_c and as_*_S patterns no longer match the above
therefore additional patterns are needed.

Signed-off-by: Nicolas Pitre <[email protected]>
Signed-off-by: Michal Marek <[email protected]>

show more ...

kbuild: add fine grained build dependencies for exported symbols

Like with kconfig options, we now have the ability to compile in and
out individual EXPORT_SYMBOL() declarations based on the content

kbuild: add fine grained build dependencies for exported symbols

Like with kconfig options, we now have the ability to compile in and
out individual EXPORT_SYMBOL() declarations based on the content of
include/generated/autoksyms.h. However we don't want the entire
world to be rebuilt whenever that file is touched.

Let's apply the same build dependency trick used for CONFIG_* symbols
where the time stamp of empty files whose paths matching those symbols
is used to trigger fine grained rebuilds. In our case the key is the
symbol name passed to EXPORT_SYMBOL().

However, unlike config options, we cannot just use fixdep to parse
the source code for EXPORT_SYMBOL(ksym) because several variants exist
and parsing them all in a separate tool, and keeping it in synch, is
not trivially maintainable. Furthermore, there are variants such as

EXPORT_SYMBOL_GPL(pci_user_read_config_##size);

that are instanciated via a macro for which we can't easily determine
the actual exported symbol name(s) short of actually running the
preprocessor on them.

Storing the symbol name string in a special ELF section doesn't work
for targets that output assembly or preprocessed source.

So the best way is really to leverage the preprocessor by having it
output actual symbol names anchored by a special sequence that can be
easily filtered out. Then the list of symbols is simply fed to fixdep
to be merged with the other dependencies.

That implies the preprocessor is executed twice for each source file.
A previous attempt relied on a warning pragma for each EXPORT_SYMBOL()
instance that was filtered apart from stderr by the build system with
a sed script during the actual compilation pass. Unfortunately the
preprocessor/compiler diagnostic output isn't stable between versions
and this solution, although more efficient, was deemed too fragile.

Because of the lowercasing performed by fixdep, there might be name
collisions triggering spurious rebuilds for similar symbols. But this
shouldn't be a big issue in practice. (This is the case for CONFIG_*
symbols and I didn't want to be different here, whatever the original
reason for doing so.)

To avoid needless build overhead, the exported symbol name gathering is
performed only when CONFIG_TRIM_UNUSED_KSYMS is selected.

Signed-off-by: Nicolas Pitre <[email protected]>
Acked-by: Rusty Russell <[email protected]>

show more ...

kbuild: de-duplicate fixdep usage

The generation and postprocessing of automatic dependency rules is
duplicated in rule_cc_o_c, rule_as_o_S and if_changed_dep. Since
this is not a trivial one-liner

kbuild: de-duplicate fixdep usage

The generation and postprocessing of automatic dependency rules is
duplicated in rule_cc_o_c, rule_as_o_S and if_changed_dep. Since
this is not a trivial one-liner action, it is now abstracted under
cmd_and_fixdep to simplify things and make future changes in this area
easier.

In the rule_cc_o_c and rule_as_o_S cases that means the order of some
commands has been altered, namely fixdep and related file manipulations
are executed earlier, but they didn't depend on those commands that now
execute later.

Signed-off-by: Nicolas Pitre <[email protected]>

show more ...

kbuild: suppress annoying "... is up to date." message

Under certain conditions, Kbuild shows "... is up to date" where
if_changed or friends are used.

For example, the incremental build of ARM64 L

kbuild: suppress annoying "... is up to date." message

Under certain conditions, Kbuild shows "... is up to date" where
if_changed or friends are used.

For example, the incremental build of ARM64 Linux shows this message
when the kernel image has not been updated.

$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CHK include/generated/bounds.h
CHK include/generated/timeconst.h
CHK include/generated/asm-offsets.h
CALL scripts/checksyscalls.sh
CHK include/generated/compile.h
CHK kernel/config_data.h
make[1]: `arch/arm64/boot/Image.gz' is up to date.
Building modules, stage 2.
MODPOST 0 modules

The following is the build rule in arch/arm64/boot/Makefile:

$(obj)/Image.gz: $(obj)/Image FORCE
$(call if_changed,gzip)

If the Image.gz is newer than the Image and the command line has not
changed (i.e., $(any-prereq) and $(arg-check) are both empty), the
build rule $(call if_changed,gzip) is evaluated to be empty, then
GNU Make reports the target is up to date. In order to make GNU Make
quiet, we need to give it something to do, for example, "@:". This
should be fixed in the Kbuild core part rather than in each Makefile.

Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Michal Marek <[email protected]>

show more ...

kbuild: Fix clang detection

We cannot detect clang before including the arch Makefile, because that
can set the default cross compiler. We also cannot detect clang after
including the arch Makefile,

kbuild: Fix clang detection

We cannot detect clang before including the arch Makefile, because that
can set the default cross compiler. We also cannot detect clang after
including the arch Makefile, because powerpc wants to know about clang.
Solve this by using an deferred variable. This costs us a few shell
invocations, but this is only a constant number.

Reported-by: Behan Webster <[email protected]>
Reported-by: Anton Blanchard <[email protected]>
Signed-off-by: Michal Marek <[email protected]>

show more ...

modsign: Handle signing key in source tree

Since commit 1329e8cc69 ("modsign: Extract signing cert from
CONFIG_MODULE_SIG_KEY if needed"), the build system has carefully coped
with the signing key b

modsign: Handle signing key in source tree

Since commit 1329e8cc69 ("modsign: Extract signing cert from
CONFIG_MODULE_SIG_KEY if needed"), the build system has carefully coped
with the signing key being specified as a relative path in either the
source or or the build trees.

However, the actual signing of modules has not worked if the filename
is relative to the source tree.

Fix that by moving the config_filename helper into scripts/Kbuild.include
so that it can be used from elsewhere, and then using it in the top-level
Makefile to find the signing key file.

Kill the intermediate $(MODPUBKEY) and $(MODSECKEY) variables too, while
we're at it. There's no need for them.

Signed-off-by: David Woodhouse <[email protected]>
Signed-off-by: David Howells <[email protected]>

show more ...

kbuild: allow cc-ifversion to have the argument for false condition

The macro "try-run" can have an argument for each of true and false
cases. Having an argument for the false case of cc-ifversion

kbuild: allow cc-ifversion to have the argument for false condition

The macro "try-run" can have an argument for each of true and false
cases. Having an argument for the false case of cc-ifversion (and
ld-ifversion) would be useful too.

Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Michal Marek <[email protected]>

show more ...

kbuild: do not add $(call ...) to invoke cc-version or cc-fullversion

The macros cc-version, cc-fullversion and ld-version take no argument.
It is not necessary to add $(call ...) to invoke them.

S

kbuild: do not add $(call ...) to invoke cc-version or cc-fullversion

The macros cc-version, cc-fullversion and ld-version take no argument.
It is not necessary to add $(call ...) to invoke them.

Signed-off-by: Masahiro Yamada <[email protected]>
Acked-by: Helge Deller <[email protected]> [parisc]
Signed-off-by: Michal Marek <[email protected]>

show more ...

kbuild: fix cc-ifversion macro

The macro "cc-version" takes no argument. Drop $(CC) from the
"cc-ifversion" definition.

Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Mi

kbuild: fix cc-ifversion macro

The macro "cc-version" takes no argument. Drop $(CC) from the
"cc-ifversion" definition.

Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Michal Marek <[email protected]>

show more ...

kbuild: remove redundant -rR flag of hdr-inst

Passing -rR for "make headers_install" is redundant because
the top Makefile has already set -rR to MAKEFLAGS.

Signed-off-by: Masahiro Yamada <yamada.m

kbuild: remove redundant -rR flag of hdr-inst

Passing -rR for "make headers_install" is redundant because
the top Makefile has already set -rR to MAKEFLAGS.

Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Michal Marek <[email protected]>

show more ...

kbuild: collect shorthands into scripts/Kbuild.include

The shorthand "clean" is defined in both the top Makefile and
scripts/Makefile.clean. Likewise, the "hdr-inst" is defined in
both the top Make

kbuild: collect shorthands into scripts/Kbuild.include

The shorthand "clean" is defined in both the top Makefile and
scripts/Makefile.clean. Likewise, the "hdr-inst" is defined in
both the top Makefile and scripts/Makefile.headersinst.

To reduce code duplication, this commit collects them into
scripts/Kbuild.include like the "build" and "modbuiltin" shorthands.
It requires scripts/Makefile.clean to include scripts/Kbuild.include,
but its impact on the performance of "make clean" should be
negligible.

Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Michal Marek <[email protected]>

show more ...