The kbuild cache was introduced to remember the result of shell
commands, some of which are expensive to compute, such as
$(call cc-option,...).
However, this turned out not so clever as I had first expected.
Actually, it is problematic. For example, "$(CC) -print-file-name"
is cached. If the compiler is updated, the stale search path causes
build error, which is difficult to figure out. Another problem
scenario is cache files could be touched while install targets are
running under the root permission. We can patch them if desired,
but the build infrastructure is getting uglier and uglier.
Now, we are going to move compiler flag tests to the configuration
phase. If this is completed, the result of compiler tests will be
naturally cached in the .config file. We will not have performance
issues of incremental building since this testing only happens at
Kconfig time.
To start this work with a cleaner code base, remove the kbuild
cache first.
Revert the following commits:
Commit 9a234a2e38 ("kbuild: create directory for make cache only when necessary")
Commit e17c400ae1 ("kbuild: shrink .cache.mk when it exceeds 1000 lines")
Commit 4e56207130 ("kbuild: Cache a few more calls to the compiler")
Commit 3298b690b2 ("kbuild: Add a cache for generated variables")
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
filechk displays two short logs; CHK for creating a temporary file,
and UPD for really updating the target.
IMHO, the build system can be quiet when the target file has not
been updated.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
I tried building using a freshly built Make (4.2.1-69-g8a731d1), but
already the objtool build broke with
orc_dump.c: In function ‘orc_dump’:
orc_dump.c:106:2: error: ‘elf_getshnum’ is deprecated [-Werror=deprecated-declarations]
if (elf_getshdrnum(elf, &nr_sections)) {
Turns out that with that new Make, the backslash was not removed, so cpp
didn't see a #include directive, grep found nothing, and
-DLIBELF_USE_DEPRECATED was wrongly put in CFLAGS.
Now, that new Make behaviour is documented in their NEWS file:
* WARNING: Backward-incompatibility!
Number signs (#) appearing inside a macro reference or function invocation
no longer introduce comments and should not be escaped with backslashes:
thus a call such as:
foo := $(shell echo '#')
is legal. Previously the number sign needed to be escaped, for example:
foo := $(shell echo '\#')
Now this latter will resolve to "\#". If you want to write makefiles
portable to both versions, assign the number sign to a variable:
C := \#
foo := $(shell echo '$C')
This was claimed to be fixed in 3.81, but wasn't, for some reason.
To detect this change search for 'nocomment' in the .FEATURES variable.
This also fixes up the two make-cmd instances to replace # with $(pound)
rather than with \#. There might very well be other places that need
similar fixup in preparation for whatever future Make release contains
the above change, but at least this builds an x86_64 defconfig with the
new make.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=197847
Cc: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The idea of using fixdep was inspired by Kconfig, but autoksyms
belongs to a different group. So, I want to move those touched
files under include/config/ksym/ to include/ksym/.
The directory include/ksym/ can be removed by 'make clean' because
it is meaningless for the external module building.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Currently, linker options are tested by the coordination of $(CC) and
$(LD) because $(LD) needs some object to link.
As commit 86a9df597c ("kbuild: fix linker feature test macros when
cross compiling with Clang") addressed, we need to make sure $(CC)
and $(LD) agree the underlying architecture of the passed object.
This could be a bit complex when we combine tools from different groups.
For example, we can use clang for $(CC), but we still need to rely on
GCC toolchain for $(LD).
So, I was searching for a way of standalone testing of linker options.
A trick I found is to use '-v'; this not only prints the version string,
but also tests if the given option is recognized.
If a given option is supported,
$ aarch64-linux-gnu-ld -v --fix-cortex-a53-843419
GNU ld (Linaro_Binutils-2017.11) 2.28.2.20170706
$ echo $?
0
If unsupported,
$ aarch64-linux-gnu-ld -v --fix-cortex-a53-843419
GNU ld (crosstool-NG linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) 2.23.1
aarch64-linux-gnu-ld: unrecognized option '--fix-cortex-a53-843419'
aarch64-linux-gnu-ld: use the --help option for usage information
$ echo $?
1
Gold works likewise.
$ aarch64-linux-gnu-ld.gold -v --fix-cortex-a53-843419
GNU gold (Linaro_Binutils-2017.11 2.28.2.20170706) 1.14
masahiro@pug:~/ref/linux$ echo $?
0
$ aarch64-linux-gnu-ld.gold -v --fix-cortex-a53-999999
GNU gold (Linaro_Binutils-2017.11 2.28.2.20170706) 1.14
aarch64-linux-gnu-ld.gold: --fix-cortex-a53-999999: unknown option
aarch64-linux-gnu-ld.gold: use the --help option for usage information
$ echo $?
1
LLD too.
$ ld.lld -v --gc-sections
LLD 7.0.0 (http://llvm.org/git/lld.git 4a0e4190e74cea19f8a8dc625ccaebdf8b5d1585) (compatible with GNU linkers)
$ echo $?
0
$ ld.lld -v --fix-cortex-a53-843419
LLD 7.0.0 (http://llvm.org/git/lld.git 4a0e4190e74cea19f8a8dc625ccaebdf8b5d1585) (compatible with GNU linkers)
$ echo $?
0
$ ld.lld -v --fix-cortex-a53-999999
ld.lld: error: unknown argument: --fix-cortex-a53-999999
LLD 7.0.0 (http://llvm.org/git/lld.git 4a0e4190e74cea19f8a8dc625ccaebdf8b5d1585) (compatible with GNU linkers)
$ echo $?
1
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
* Use BREs where EREs aren't necessary.
* Pass -E instead of -r to use EREs. This will be standardized in the
next POSIX revision[0]. GNU sed supports this since 4.2 (May 2009),
and busybox since 1.22.0 (Jan 2014).
* Use the [:space:] character class instead of ` \t` in bracket
expressions. In bracket expressions, POSIX says that <backslash> loses
its special meaning, so a conforming implementation cannot expand \t
to <tab>[1].
* In BREs, use interval expressions (\{n,m\}) instead of non-standard
features like \+ and \?.
* Use a loop instead of -s flag.
There are still plenty of other cases of non-standard sed invocations
(use of ERE features in BREs, in-place editing), but this fixes some
core ones.
[0] http://austingroupbugs.net/view.php?id=528
[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_03_05
Signed-off-by: Michael Forney <forney@google.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Currently, the existence of $(dir $(make-cache)) is always checked,
and created if it is missing.
We can avoid unnecessary system calls by some tricks.
[1] If KBUILD_SRC is unset, we are building in the source tree.
The output directory checks can be entirely skipped.
[2] If at least one cache data is found, it means the cache file
was included. Obviously its directory exists. Skip "mkdir -p".
[3] If Makefile does not contain any call of __run-and-store, it will
not create a cache file. No need to create its directory.
[4] The "mkdir -p" should be only invoked by the first call of
__run-and-store
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
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 <yamada.masahiro@socionext.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
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 <yamada.masahiro@socionext.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
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 <dianders@chromium.org>
Tested-by: Ingo Molnar <mingo@kernel.org>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This is a bunch of trivial fixes and cleanups.
Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
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 <arnd@arndb.de>
Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Michal Marek <mmarek@suse.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
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 <yamada.masahiro@socionext.com>
Acked-by: Ingo Molnar <mingo@kernel.org>
- Improve Clang support
- Clean up various Makefiles
- Improve build log visibility (objtool, alpha, ia64)
- Improve compiler flag evaluation for better build performance
- Fix GCC version-dependent warning
- Fix genksyms
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJZE6qLAAoJED2LAQed4NsGk8YP/R7ZajSruFRmathN+wO1GEUv
+1cIJVpCv8OpM9fCSIuV3udAUUrH7Sj5IgHdg4P05/qmlgsG/4kUL5r9RyKdwjrA
dWqp8KKh40/JAfYNlMcRGz3cB4csvhMhnzZgV0zMSM1BBPP/xu2bCXrD4f/TGFMg
q04hHkmkesV0RUqOyPsCrKusxIsHhaGOmYUB285omGHO85IRItAW5CPh6sMhoJuQ
x7d5ZaXKCUH2fHXVMaw7gXcg28loUfKVJcU+em/0YZxoNZ31y6brM5YY7buF4FoJ
5RTXlvm12TUygY3fFCb3NURDSILHmL8Wk2wgFgYAC3NnXH1KJDOM4xxKXIVtTLGw
d71/hAurlLLZzjwmdUSSrhD+1OjFRZ4a5TJK/o3xehKUzYmFB49bcSKwdQ4H0jnM
m4iqNHw3rK+LJ0Zp71Ki3k3mcSW9yovpnJ2Uzi5Oz7g+oYAob7SZjejL2KsCtxZH
sQZQE5YeZj39Ot1K3Zw9CWx3JcUXWKtNu8cH7hXBgCyKS7H56xgtmib/S2yjXGu0
YIaMFJWTEB+FLrHRB4fYmeLG/kXIRn+N8Gy+/QUeXEHp4dFTV/il4Q2W+JAG35MS
3IGMr8PEZA7gTSYDQ/2kpv0HXDCwYSDxN3p8dlrnLy1bokVJX7Nk1pNq6gXfOl/E
4zIj3UsK0gPyO+CgprwC
=Nka/
-----END PGP SIGNATURE-----
Merge tag 'kbuild-v4.12' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
Pull Kbuild updates from Masahiro Yamada:
- improve Clang support
- clean up various Makefiles
- improve build log visibility (objtool, alpha, ia64)
- improve compiler flag evaluation for better build performance
- fix GCC version-dependent warning
- fix genksyms
* tag 'kbuild-v4.12' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (23 commits)
kbuild: dtbinst: remove unnecessary __dtbs_install_prep target
ia64: beatify build log for gate.so and gate-syms.o
alpha: make short build log available for division routines
alpha: merge build rules of division routines
alpha: add $(src)/ rather than $(obj)/ to make source file path
Makefile: evaluate LDFLAGS_BUILD_ID only once
objtool: make it visible in make V=1 output
kbuild: clang: add -no-integrated-as to KBUILD_[AC]FLAGS
kbuild: Add support to generate LLVM assembly files
kbuild: Add better clang cross build support
kbuild: drop -Wno-unknown-warning-option from clang options
kbuild: fix asm-offset generation to work with clang
kbuild: consolidate redundant sed script ASM offset generation
frv: Use OFFSET macro in DEF_*REG()
kbuild: avoid conflict between -ffunction-sections and -pg on gcc-4.7
kbuild: Consolidate header generation from ASM offset information
kbuild: use -Oz instead of -Os when using clang
kbuild, LLVMLinux: Add -Werror to cc-option to support clang
Kbuild: make designated_init attribute fatal
kbuild: drop unneeded patterns '.*.orig' and '.*.rej' from distclean
...
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 <charlebm@gmail.com>
Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
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 <jpoimboe@redhat.com>
Cc: Andrew Lutomirski <luto@kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20170316193133.zrj6gug53766m6nn@treble
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Add a new command cpp_its_S introduced in commit cf2a5e0bb4 ("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 <marcin.nowakowski@imgtec.com>
Cc: Michal Marek <mmarek@suse.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/15278/
Signed-off-by: James Hogan <james.hogan@imgtec.com>
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 <arnd@arndb.de>
Signed-off-by: Michal Marek <mmarek@suse.com>
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 <arnd@arndb.de>
Signed-off-by: Michal Marek <mmarek@suse.com>
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 <yamada.masahiro@socionext.com>
Signed-off-by: Michal Marek <mmarek@suse.com>
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 <arnd@arndb.de>
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Michal Marek <mmarek@suse.com>
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 <nico@linaro.org>
Signed-off-by: Michal Marek <mmarek@suse.com>
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 <nico@linaro.org>
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
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 <nico@linaro.org>
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 <yamada.masahiro@socionext.com>
Signed-off-by: Michal Marek <mmarek@suse.com>
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 <behanw@converseincode.com>
Reported-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Michal Marek <mmarek@suse.com>
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 <David.Woodhouse@intel.com>
Signed-off-by: David Howells <dhowells@redhat.com>
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 <yamada.m@jp.panasonic.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
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 <yamada.m@jp.panasonic.com>
Acked-by: Helge Deller <deller@gmx.de> [parisc]
Signed-off-by: Michal Marek <mmarek@suse.cz>
The macro "cc-version" takes no argument. Drop $(CC) from the
"cc-ifversion" definition.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Pull kbuild updates from Michal Marek:
"Here are the kbuild changes for v3.19-rc1:
- Cleanups and deduplication in the main Makefile and
scripts/Makefile.*
- Sort the output of *config targets in make help
- Old <linux/version.h> is always removed to avoid a surprise during
bisecting
- Warning fix in kconfig"
* 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
kbuild: remove redundant -rR flag of hdr-inst
kbuild: Fix make help-<board series> on powerpc
kbuild: Automatically remove stale <linux/version.h> file
kconfig: Fix warning "‘jump’ may be used uninitialized"
Makefile: sort list of defconfig targets in make help output
kbuild: Remove duplicate $(cmd) definition in Makefile.clean
kbuild: collect shorthands into scripts/Kbuild.include
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@jp.panasonic.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
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 <yamada.m@jp.panasonic.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Move dtbs install rules to Makefile.dtbinst. This change is needed to
implement support for dts vendor subdirs. The change makes Makefiles
easier and smaller as no longer the dtbs_install rule needs to be
defined. Another advantage is that install goals are not encoded in
targets anymore (%.dtb_dtbinst_).
Signed-off-by: Robert Richter <rrichter@cavium.com>
$(if $(KBUILD_SRC),$(srctree)/) was a useful strategy
to omit a long absolute path for in-source-tree build
prior to commit 890676c65d
(kbuild: Use relative path when building in the source tree).
Now $(srctree) is "." when building in the source tree.
It would not be annoying to add "$(srctree)/" all the time.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Commit c353acba ("kbuild: make: fix if_changed when command contains
backslashes") attempted to handle backslashes in *.cmd files, but it
only handled double backslashes for some reason. Changing make-cmd to also
handle single backslashes fixes rebuilds with dash, but it breaks bash
again. The reason is that the two shells disagree about the
interpretation of backslash sequences in the echo builtin. The way out
of this is to print the command with printf '%s\n'. While at it,
document what the individual parts of make-cmd do and why.
Reported-and-tested-by: Konstantin Khlebnikov <koct9i@gmail.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Pull kbuild changes from Michal Marek:
- cleanups in the main Makefiles and Documentation/DocBook/Makefile
- make O=... directory is automatically created if needed
- mrproper/distclean removes the old include/linux/version.h to make
life easier when bisecting across the commit that moved the version.h
file
* 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
kbuild: docbook: fix the include error when executing "make help"
kbuild: create a build directory automatically for out-of-tree build
kbuild: remove redundant '.*.cmd' pattern from make distclean
kbuild: move "quote" to Kbuild.include to be consistent
kbuild: docbook: use $(obj) and $(src) rather than specific path
kbuild: unconditionally clobber include/linux/version.h on distclean
kbuild: docbook: specify KERNELDOC dependency correctly
kbuild: docbook: include cmd files more simply
kbuild: specify build_docproc as a phony target
The kbuild's ld-option function is broken because
the command
$(CC) /dev/null -c -o "$$TMPO"
does not create object file!
I have used a relatively old mips gcc 3.4.6 cross-compiler
and a relatively new gcc 4.7.2 to check this fact
but the results are the same.
EXAMPLE:
$ rm /tmp/1.o
$ mips-linux-gcc /dev/null -c -o /tmp/1.o
mips-linux-gcc: /dev/null: linker input file unused because linking not done
$ ls -la /tmp/1.o
ls: cannot access /tmp/1.o: No such file or directory
We can easily fix the problem by adding
the '-x c' compiler option.
EXAMPLE:
$ rm /tmp/1.o
$ mips-linux-gcc -x c /dev/null -c -o /tmp/1.o
$ ls -la /tmp/1.o
-rw-r--r-- 1 antony antony 778 Apr 2 20:40 /tmp/1.o
Also fix wrong ld-option example.
Signed-off-by: Antony Pavlov <antonynpavlov@gmail.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Pull kbuild fixes from Michal Marek:
"Here are two fixes I intended to send after v3.6-rc7, but failed to do
so. So please pull them for v3.7-rc1 and they will be picked up by
stable.
The first one fixes gcc -x <language> syntax in various build-time
tests, which icecream and possible other gcc wrappers did not
understand (and yes, icecream is going to be fixed as well).
The second one fixes make tar-pkg so that unpacking the tarball does
not replace the /lib -> /usr/lib symlink on recent Fedora releases."
* 'rc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
kbuild: Fix gcc -x syntax
kbuild: Do not package /boot and /lib in make tar-pkg
The call if_changed mechanism does not work when the command contains
backslashes. This basically is an issue with lzo and bzip2 compressed
kernels. The compressed binaries do not contain the uncompressed image
size, so these use size_append to append the size. This results in
backslashes in the executed command. With this if_changed always
detects a change in the command and rebuilds the compressed image even
if nothing has changed.
Fix this by escaping backslashes in make-cmd
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Bernhard Walle <bernhard@bwalle.de>
Cc: Michal Marek <mmarek@suse.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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: Jean Delvare <jdelvare@suse.de>
Acked-by: Ingo 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: Michal Marek <mmarek@suse.cz>
"echo -e" is a GNU extension. When cross-compiling the kernel on a
BSD-like operating system (Mac OS X in my case), this doesn't work.
One could install a GNU version of echo, put that in the $PATH before
the system echo and use "/usr/bin/env echo", but the solution with
printf is simpler.
Since it is no disadvantage on Linux, I hope that gets accepted even if
cross-compiling the Linux kernel on another Unix operating system is
quite a rare use case.
Signed-off-by: Bernhard Walle <bernhard@bwalle.de>
Andreas Bießmann <andreas@biessmann.de>
Signed-off-by: Michal Marek <mmarek@suse.cz>
On the same model as `basetarget', it represents the filename of first
prerequisite with directory and extension stripped.
Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
Based on a patch by Rabin Vincent.
Fix building with KBUILD_NOCMDDEP=1, which currently does not work
because it does not build built-in.o with no dependencies:
LD fs/notify/built-in.o
ld: cannot find fs/notify/dnotify/built-in.o: No such file or directory
ld: cannot find fs/notify/inotify/built-in.o: No such file or directory
ld: cannot find fs/notify/fanotify/built-in.o: No such file or directory
Reported-and-tested-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Starting with 4.4, gcc will happily accept -Wno-<anything> in the
cc-option test and complain later when compiling a file that has some
other warning. This rather unexpected behavior is intentional as per
http://gcc.gnu.org/PR28322, so work around it by testing for support of
the opposite option (without the no-). Introduce a new Makefile function
cc-disable-warning that does this and update two uses of cc-option in
the toplevel Makefile.
Reported-and-tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Michal Marek <mmarek@suse.cz>
To make it easier for module-init-tools and scripts like mkinitrd to
distinguish builtin and missing modules, install a modules.builtin file
listing all builtin modules. This is done by generating an additional
config file (tristate.conf) with tristate options set to uppercase 'Y'
or 'M'. If we source that config file, the builtin modules appear in
obj-Y.
Signed-off-by: Michal Marek <mmarek@suse.cz>
Alek reported that on Ubuntu, where dash is used, 'echo -e'
can't work, so let's use non-builtin echo in this case.
Reported-by: Alek Du <alek.du@intel.com>
Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
The arch/*/boot/Makefile use cc-options to check for GCC command options
and cc-options use the hardened specs when checking for GCC command
options. When -fPIE is pass to cc1 it can't use -ffreestanding or
-fno-toplevel-reorder. Then it fail to build stuff with -ffreestanding
and -fno-toplevel-reorder.
Thanks to Fredric Johansson for finding the main problem behind a failed
build using a hardened toolchain.
Signed-off-by: Magnus Granberg <zorry@ume.nu>
Signed-off-by: Jory A. Pratt <anarchy@gentoo.org>
Cc: Fredric Johansson <johansson_fredric@hotmail.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: <stable@kernel.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
ld-option is used to check if $(LD) supports a specific option.
Based on patch from Andi Kleen.
Cc: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
First use is to check if option -X is supported (upcoming patch).
Theis is ne
ld-option is misnamed as it test options to gcc, not to ld.
Renamed it to reflect this.
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Roland McGrath <roland@redhat.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Convert a few echos in the build system to new $(kecho) so we get correct
output according to build verbosity.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
[sam: added kecho in a few more places for O=... builds]
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
There is a bunch of places in the build system where we do 'echo' to show
some nice status lines. This means we still get output when running in
silent mode. So declare a new KECHO variable that only does 'echo' when we
are in a suitable verbose build mode.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
[sam: added Documentation]
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
When adding extra -I options with O=... we could
end up in a situation where there were no parameters to -I.
So we had a commandline that looked like this:
... -I -Wall ...
This had the undesired side effect that gcc assumed "-Wall"
was a path to look for include files so this options was
effectively ignored.
This happens only when we build the generated module.mod.c files
as part of the final modules builds and is as such harmless
with current kbuild.
This bug was exposed when we rearranged the options to gcc.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
David Sanders wrote:
> I'm getting this error:
> as: unrecognized option `-mtune=generic32'
> I have binutils 2.17.
Use -c instead of -S in cc-option and cc-option-yn, so we can probe
options related to the assembler.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: kbuild devel <kbuild-devel@lists.sourceforge.net>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
When make -s support were added to filechk to
combination created with make V=1 were not
covered.
Fix it by explicitly cover this case too.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Mike Frysinger <vapier@gentoo.org>
cc-cross-prefix is useful for the architecture that like
to provide a default CROSS_COMPILE value,
but may have several to select between.
Sample usage:
ifneq ($(SUBARCH),$(ARCH))
ifeq ($(CROSS_COMPILE),)
CROSS_COMPILE := $(call cc-cross-prefix, m68k-linux-gnu- m68k-linux-)
endif
endif
Actual usage by the different archs will taken care of later.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
The variable AFLAGS is a wellknown variable and the usage by
kbuild may result in unexpected behaviour.
On top of that several people over time has asked for a way to
pass in additional flags to gcc.
This patch replace use of AFLAGS with KBUILD_AFLAGS all over
the tree.
Patch was tested on following architectures:
alpha, arm, i386, x86_64, mips, sparc, sparc64, ia64, m68k, s390
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
The variable CFLAGS is a wellknown variable and the usage by
kbuild may result in unexpected behaviour.
On top of that several people over time has asked for a way to
pass in additional flags to gcc.
This patch replace use of CFLAGS with KBUILD_CFLAGS all over the
tree and enabling one to use:
make CFLAGS=...
to specify additional gcc commandline options.
One usecase is when trying to find gcc bugs but other
use cases has been requested too.
Patch was tested on following architectures:
alpha, arm, i386, x86_64, mips, sparc, sparc64, ia64, m68k
Test was simple to do a defconfig build, apply the patch and check
that nothing got rebuild.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Prints a six-digit string including the GCC patchlevel. Also fix
the 'usage' comment for cc-version.
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
This adds the remaining changes which should have been part of the
review process.
- the define command is inappropriate (it's primarily for rule
definitions)
- execute commands in the current dir as all other commands
- .*.tmp (but not .*.null) files are also removed up by "make clean"
- printf has other side effects, just use "echo -e"
- proper quoting
- proper indentation
Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Michal Ostrowski points out what the real problem was: the spaces at the
start of the definition of the 'checker-shell' make function.
Cc: Michal Ostrowski <mostrows@watson.ibm.com>
Acked-by: David Miller <davem@davemloft.net>
Acked-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Acked-by: Oleg Verych <olecom@flower.upol.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It looks like GNU make version 3.80 (but apparently not 3.81) adds
leading whitespace to the result of the checker-shell execution. This
strips them off explicitly.
Also, don't bother symlinking the output file to /dev/null. It's likely
as expensive as just writing the temp-file, and we need to remove it
anyway afterwards.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Do not use whitespace in arguments of functions in makefiles, as they
propagate further without notice. Thus we get
+ echo ' y'
instead of
+ echo y
Fix misleading comments.
Signed-off-by: Oleg Verych <olecom@flower.upol.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
GNU binutils, root users, tmpfiles, external modules ro builds must
be fixed to do the right thing now.
Cc: Roman Zippel <zippel@linux-m68k.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Horst Schirmeier <horst@schirmeier.com>
Cc: Jan Beulich <jbeulich@novell.com>
Cc: Daniel Drake <dsd@gentoo.org>
Cc: Andi Kleen <ak@suse.de>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Oleg Verych <olecom@flower.upol.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The as-instr/ld-option need to create temporary files, but create them in the
output directory, when compiling external modules. Reformat them a bit and
use $(CC) instead of $(AS) as the former is used by kbuild to assemble files.
Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
Cc: Andi Kleen <ak@suse.de>
Cc: Jan Beulich <jbeulich@novell.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: <jpdenheijer@gmail.com>
Cc: Horst Schirmeier <horst@schirmeier.com>
Cc: Daniel Drake <dsd@gentoo.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Current gcc generates calls not jumps to noreturn functions. When that happens the
return address can point to the next function, which confuses the unwinder.
This patch works around it by marking asynchronous exception
frames in contrast normal call frames in the unwind information. Then teach
the unwinder to decode this.
For normal call frames the unwinder now subtracts one from the address which avoids
this problem. The standard libgcc unwinder uses the same trick.
It doesn't include adjustment of the printed address (i.e. for the original
example, it'd still be kernel_math_error+0 that gets displayed, but the
unwinder wouldn't get confused anymore.
This only works with binutils 2.6.17+ and some versions of H.J.Lu's 2.6.16
unfortunately because earlier binutils don't support .cfi_signal_frame
[AK: added automatic detection of the new binutils and wrote description]
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andi Kleen <ak@suse.de>
... instead of using a CONFIG option. The config option still controls
if the resulting executable actually has unwind information.
This is useful to prevent compilation errors when users select
CONFIG_STACK_UNWIND on old binutils and also allows to use
CFI in the future for non kernel debugging applications.
Cc: jbeulich@novell.com
Cc: sam@ravnborg.org
Signed-off-by: Andi Kleen <ak@suse.de>
tell why a a target got build
enabled by make V=2
Output (listed in the order they are checked):
(1) - due to target is PHONY
(2) - due to target missing
(3) - due to: file1.h file2.h
(4) - due to command line change
(5) - due to missing .cmd file
(6) - due to target not in $(targets)
(1) We always build PHONY targets
(2) No target, so we better build it
(3) Prerequisite is newer than target
(4) The command line stored in the file named dir/.target.cmd
differed from actual command line. This happens when compiler
options changes
(5) No dir/.target.cmd file (used to store command line)
(6) No dir/.target.cmd file and target not listed in $(targets)
This is a good hint that there is a bug in the kbuild file
This patch is inspired by a patch from: Milton Miller <miltonm@bga.com>
Cc: Milton Miller <miltonm@bga.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Consistently decide when to rebuild a target across all of
if_changed, if_changed_dep, if_changed_rule.
PHONY targets are now treated alike (ignored) for all targets
While add it make Kbuild.include almost readable by factoring out a few
bits to some common variables and reuse this in Makefile.build.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
The possibility to specify an optional parameter did not work out as
expected and it was not used - so remove the possibility.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
The latest toolchains can produce a new ELF section in DSOs and
dynamically-linked executables. The new section ".gnu.hash" replaces
".hash", and allows for more efficient runtime symbol lookups by the
dynamic linker. The new ld option --hash-style={sysv|gnu|both} controls
whether to produce the old ".hash", the new ".gnu.hash", or both. In some
new systems such as Fedora Core 6, gcc by default passes --hash-style=gnu
to the linker, so that a standard invocation of "gcc -shared" results in
producing a DSO with only ".gnu.hash". The new ".gnu.hash" sections need
to be dealt with the same way as ".hash" sections in all respects; only the
dynamic linker cares about their contents. To work with older dynamic
linkers (i.e. preexisting releases of glibc), a binary must have the old
".hash" section. The --hash-style=both option produces binaries that a new
dynamic linker can use more efficiently, but an old dynamic linker can
still handle.
The new section runs afoul of the custom linker scripts used to build vDSO
images for the kernel. On ia64, the failure mode for this is a boot-time
panic because the vDSO's PT_IA_64_UNWIND segment winds up ill-formed.
This patch addresses the problem in two ways.
First, it mentions ".gnu.hash" in all the linker scripts alongside ".hash".
This produces correct vDSO images with --hash-style=sysv (or old tools),
with --hash-style=gnu, or with --hash-style=both.
Second, it passes the --hash-style=sysv option when building the vDSO
images, so that ".gnu.hash" is not actually produced. This is the most
conservative choice for compatibility with any old userland. There is some
concern that some ancient glibc builds (though not any known old production
system) might choke on --hash-style=both binaries. The optimizations
provided by the new style of hash section do not really matter for a DSO
with a tiny number of symbols, as the vDSO has. If someone wants to use
=gnu or =both for their vDSO builds and worry less about that
compatibility, just change the option and the linker script changes will
make any choice work fine.
Signed-off-by: Roland McGrath <roland@redhat.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Cc: Kyle McMartin <kyle@mcmartin.ca>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Andi Kleen <ak@muc.de>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
kbuild used $¤(*F to get filename of target without extension.
This was used in several places all over kbuild, but introducing
make -rR broke his for all cases where we specified full path to
target/prerequsite. It is assumed that make -rR disables old style
suffix-rules which is why is suddenly failed.
ia64 was impacted by this change because several div* routines in
arch/ia64/lib are build using explicit paths and then kbuild failed.
Thanks to David Mosberger-Tang <David.Mosberger@acm.org> for an explanation
what was the root-cause and for testing on ia64.
This patch also fixes two uses of $(*F) in arch/um
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
This reverts commit e5c44fd88c.
Thanks to Daniel Ritz and Michal Piotrowski for noticing the problem.
Daniel says:
"[The] reason is a recent change that made modules always shows as
module.mod. it breaks modprobe and probably many scripts..besides
lsmod looking horrible
stuff like this in modprobe.conf:
install pcmcia_core /sbin/modprobe --ignore-install pcmcia_core; /sbin/modprobe pcmcia
makes modprobe fork/exec endlessly calling itself...until oom
interrupts it"
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
make failed to supply the filename when using make -rR and using $(*F)
to get target filename without extension.
This bug was not reproduceable in small scale but using:
$(basename $(notdir $@)) fixes it with same functionality.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
This fix a longstanding bug where proper options was not
passed to hostcc in case of a make O=.. build.
This bug showed up in (not yet merged) klibc, and is not known
to have any counterpart in-kernel.
Fixed by moving the flags macro to Kbuild.include so it can be used
by both Makefile.lib and Makefile.host.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
The kbuild system takes advantage of an incorrect behavior in GNU make.
Once this behavior is fixed, all files in the kernel rebuild every time,
even if nothing has changed. This patch ensures kbuild works with both
the incorrect and correct behaviors of GNU make.
For more details on the incorrect behavior, see:
http://lists.gnu.org/archive/html/bug-make/2006-03/msg00003.html
Changes in this patch:
- Keep all targets that are to be marked .PHONY in a variable, PHONY.
- Add .PHONY: $(PHONY) to mark them properly.
- Remove any $(PHONY) files from the $? list when determining whether
targets are up-to-date or not.
Signed-off-by: Paul Smith <psmith@gnu.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
While the recent change to also escape # symbols when storing C-file
compilation command lines was helpful, it should be in effect for all
command lines, as much as the dollar escaping should be in effect for
C-source compilation commands. Additionally, for better readability and
maintenance, consolidating all the escaping (single quotes, dollars,
and now sharps) was also desirable.
Signed-Off-By: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Move $(CC) support functions to Kbuild.include so they are available
in the kbuild files.
In addition the following was done:
o as-option documented in Documentation/kbuild/makefiles.txt
o Moved documentation to new section to match
new scope of functions
o added cc-ifversion used to conditionally select a text string
dependent on actual $(CC) version
o documented cc-ifversion
o change so Kbuild.include is read before the kbuild file
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Use foo := $(call objectify, $(foo)) to prefix $(foo) with $(obj)/ unless
$(foo) is an absolute path.
For now no in-tree users - soon to come.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Kbuild.include is a placeholder for definitions originally present in
both the top-level Makefile and scripts/Makefile.build.
There were a slight difference in the filechk definition, so the most videly
used version was kept and usr/Makefile was adopted for this syntax.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
---
Masahiro Yamada
Rasmus Villemoes
Michael Forney
Nick Desaulniers
Douglas Anderson
Cao jin
Matthias Kaehlcke
Linus Torvalds
Mark Charlebois
Josh Poimboeuf
Marcin Nowakowski
Emese Revfy
Arnd Bergmann
Nicolas Pitre
Michal Marek
David Woodhouse
Masahiro Yamada
Robert Richter
Michal Marek
Andi Kleen
Antony Pavlov
Sascha Hauer
Jean Delvare
Bernhard Walle
Arnaud Lacombe
Amerigo Wang
Jory A. Pratt
Sam Ravnborg
Mike Frysinger
H. Peter Anvin
Sam Ravnborg
Segher Boessenkool
Roman Zippel
Linus Torvalds
Oleg Verych
Jan Beulich
Andi Kleen
Sam Ravnborg
Roland McGrath
Linus Torvalds
Paul Smith
Sam Ravnborg