1. 26 Sep, 2018 1 commit
    • Masahiro Yamada's avatar
      kbuild: add .DELETE_ON_ERROR special target · 69383cdc
      Masahiro Yamada authored
      [ Upstream commit 9c2af1c7 ]
      
      If Make gets a fatal signal while a shell is executing, it may delete
      the target file that the recipe was supposed to update.  This is needed
      to make sure that it is remade from scratch when Make is next run; if
      Make is interrupted after the recipe has begun to write the target file,
      it results in an incomplete file whose time stamp is newer than that
      of the prerequisites files.  Make automatically deletes the incomplete
      file on interrupt unless the target is marked .PRECIOUS.
      
      The situation is just the same as when the shell fails for some reasons.
      Usually when a recipe line fails, if it has changed the target file at
      all, the file is corrupted, or at least it is not completely updated.
      Yet the file’s time stamp says that it is now up to date, so the next
      time Make runs, it will not try to update that file.
      
      However, Make does not cater to delete the incomplete target file in
      this case.  We need to add .DELETE_ON_ERROR somewhere in the Makefile
      to request it.
      
      scripts/Kbuild.include seems a suitable place to add it because it is
      included from almost all sub-makes.
      
      Please note .DELETE_ON_ERROR is not effective for phony targets.
      
      The external module building should never ever touch the kernel tree.
      The following recipe fails if include/generated/autoconf.h is missing.
      However, include/config/auto.conf is not deleted since it is a phony
      target.
      
       PHONY += include/config/auto.conf
      
       include/config/auto.conf:
               $(Q)test -e include/generated/autoconf.h -a -e $@ || (          \
               echo >&2;                                                       \
               echo >&2 "  ERROR: Kernel configuration is invalid.";           \
               echo >&2 "         include/generated/autoconf.h or $@ are missing.";\
               echo >&2 "         Run 'make oldconfig && make prepare' on kernel src to fix it."; \
               echo >&2 ;                                                      \
               /bin/false)
      Signed-off-by: 's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: 's avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      69383cdc
  2. 06 Jul, 2018 1 commit
    • Masahiro Yamada's avatar
      kbuild: do not drop -I without parameter · 48f6e3cf
      Masahiro Yamada authored
      The comment line for addtree says "skip if -I has no parameter".
      
      What it actually does is "drop if -I has no parameter".  For example,
      if you have the compiler flag '-I foo' (a space between), it will be
      converted to 'foo'.  This completely changes the meaning.
      
      What we want is, "do nothing" for -I without parameter so that
      '-I foo' is kept as-is.
      Signed-off-by: 's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      48f6e3cf
  3. 28 May, 2018 2 commits
    • Masahiro Yamada's avatar
      kbuild: remove kbuild cache · e08d6de4
      Masahiro Yamada authored
      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 9a234a2e ("kbuild: create directory for make cache only when necessary")
      Commit e17c400a ("kbuild: shrink .cache.mk when it exceeds 1000 lines")
      Commit 4e562071 ("kbuild: Cache a few more calls to the compiler")
      Commit 3298b690 ("kbuild: Add a cache for generated variables")
      Signed-off-by: 's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: 's avatarKees Cook <keescook@chromium.org>
      e08d6de4
    • Masahiro Yamada's avatar
      kbuild: do not display CHK for filechk · e6ecfb45
      Masahiro Yamada authored
      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: 's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: 's avatarSam Ravnborg <sam@ravnborg.org>
      e6ecfb45
  4. 10 Apr, 2018 1 commit
    • Rasmus Villemoes's avatar
      Kbuild: fix # escaping in .cmd files for future Make · 9564a8cf
      Rasmus Villemoes authored
      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: 's avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Signed-off-by: 's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      9564a8cf
  5. 25 Mar, 2018 3 commits
    • Masahiro Yamada's avatar
      kbuild: move include/config/ksym/* to include/ksym/* · fbfa9be9
      Masahiro Yamada authored
      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: 's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: 's avatarNicolas Pitre <nico@linaro.org>
      fbfa9be9
    • Masahiro Yamada's avatar
      kbuild: simplify ld-option implementation · 0294e6f4
      Masahiro Yamada authored
      Currently, linker options are tested by the coordination of $(CC) and
      $(LD) because $(LD) needs some object to link.
      
      As commit 86a9df59 ("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: 's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Tested-by: 's avatarNick Desaulniers <ndesaulniers@google.com>
      0294e6f4
    • Michael Forney's avatar
      kbuild: Improve portability of some sed invocations · 1fe7d2bb
      Michael Forney authored
      * 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_05Signed-off-by: 's avatarMichael Forney <forney@google.com>
      Signed-off-by: 's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      1fe7d2bb
  6. 16 Nov, 2017 1 commit
    • Masahiro Yamada's avatar
      kbuild: create directory for make cache only when necessary · 9a234a2e
      Masahiro Yamada authored
      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: 's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: 's avatarDouglas Anderson <dianders@chromium.org>
      9a234a2e
  7. 13 Nov, 2017 3 commits
    • Nick Desaulniers's avatar
      kbuild: fix linker feature test macros when cross compiling with Clang · 86a9df59
      Nick Desaulniers authored
      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: 's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: 's avatarNick Desaulniers <ndesaulniers@google.com>
      Reviewed-by: 's avatarMatthias Kaehlcke <mka@chromium.org>
      Signed-off-by: 's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      86a9df59
    • Masahiro Yamada's avatar
      kbuild: shrink .cache.mk when it exceeds 1000 lines · e17c400a
      Masahiro Yamada authored
      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: 's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: 's avatarDouglas Anderson <dianders@chromium.org>
      e17c400a
    • Douglas Anderson's avatar
      kbuild: Add a cache for generated variables · 3298b690
      Douglas Anderson authored
      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: 's avatarDouglas Anderson <dianders@chromium.org>
      Tested-by: 's avatarIngo Molnar <mingo@kernel.org>
      Tested-by: 's avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: 's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      3298b690
  8. 09 Aug, 2017 1 commit
  9. 25 Jun, 2017 2 commits
  10. 11 Apr, 2017 1 commit
  11. 30 Mar, 2017 1 commit
    • Josh Poimboeuf's avatar
      x86/build: Mostly disable '-maccumulate-outgoing-args' · 3f135e57
      Josh Poimboeuf authored
      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: 's avatarJosh 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@trebleSigned-off-by: 's avatarIngo Molnar <mingo@kernel.org>
      3f135e57
  12. 14 Feb, 2017 1 commit
  13. 09 Aug, 2016 1 commit
    • Emese Revfy's avatar
      kbuild: no gcc-plugins during cc-option tests · d26e9414
      Emese Revfy authored
      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: 's avatarLaura Abbott <labbott@redhat.com>
      Signed-off-by: 's avatarEmese Revfy <re.emese@gmail.com>
      [kees: renamed variable, clarified commit message]
      Signed-off-by: 's avatarKees Cook <keescook@chromium.org>
      d26e9414
  14. 18 Jul, 2016 2 commits
    • Arnd Bergmann's avatar
      Kbuild: don't add obj tree in additional includes · db547ef1
      Arnd Bergmann authored
      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: 's avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: 's avatarMichal Marek <mmarek@suse.com>
      db547ef1
    • Arnd Bergmann's avatar
      Kbuild: don't add ../../ to include path · b999596b
      Arnd Bergmann authored
      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: 's avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: 's avatarMichal Marek <mmarek@suse.com>
      b999596b
  15. 10 May, 2016 2 commits
    • Masahiro Yamada's avatar
      kbuild: fix if_change and friends to consider argument order · 9c8fa9bc
      Masahiro Yamada authored
      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: 's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: 's avatarMichal Marek <mmarek@suse.com>
      9c8fa9bc
    • Nicolas Pitre's avatar
      kbuild: fix ksym_dep_filter when multiple EXPORT_SYMBOL() on the same line · f110e0fe
      Nicolas Pitre authored
      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: 's avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: 's avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: 's avatarMichal Marek <mmarek@suse.com>
      f110e0fe
  16. 27 Apr, 2016 1 commit
  17. 29 Mar, 2016 2 commits
    • Nicolas Pitre's avatar
      kbuild: add fine grained build dependencies for exported symbols · c1a95fda
      Nicolas Pitre authored
      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: 's avatarNicolas Pitre <nico@linaro.org>
      Acked-by: 's avatarRusty Russell <rusty@rustcorp.com.au>
      c1a95fda
    • Nicolas Pitre's avatar
      kbuild: de-duplicate fixdep usage · e4aca459
      Nicolas Pitre authored
      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: 's avatarNicolas Pitre <nico@linaro.org>
      e4aca459
  18. 04 Mar, 2016 1 commit
    • Masahiro Yamada's avatar
      kbuild: suppress annoying "... is up to date." message · 2aedcd09
      Masahiro Yamada authored
      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: 's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: 's avatarMichal Marek <mmarek@suse.com>
      2aedcd09
  19. 04 Sep, 2015 1 commit
  20. 14 Aug, 2015 1 commit
    • David Woodhouse's avatar
      modsign: Handle signing key in source tree · 3ee550f1
      David Woodhouse authored
      Since commit 1329e8cc ("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: 's avatarDavid Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      3ee550f1
  21. 09 Jan, 2015 3 commits
  22. 03 Dec, 2014 1 commit
  23. 26 Nov, 2014 1 commit
  24. 21 Oct, 2014 1 commit
  25. 02 Oct, 2014 1 commit
  26. 07 Aug, 2014 1 commit
  27. 29 Mar, 2014 1 commit
  28. 14 Feb, 2014 1 commit
  29. 08 Apr, 2013 1 commit
    • Antony Pavlov's avatar
      kbuild: fix ld-option function · 5b83df2b
      Antony Pavlov authored
      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: 's avatarAntony Pavlov <antonynpavlov@gmail.com>
      Signed-off-by: 's avatarMichal Marek <mmarek@suse.cz>
      5b83df2b