1. 28 2月, 2019 1 次提交
  2. 27 2月, 2019 14 次提交
    • M
      kbuild: move ".config not found!" message from Kconfig to Makefile · 05850719
      Masahiro Yamada 提交于
      If you run "make" in a pristine source tree, currently Kbuild will
      start to build Kconfig to let it show the error message.
      
      It would be more straightforward to check it in Makefile and let
      it fail immediately.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      05850719
    • M
      kbuild: invoke syncconfig if include/config/auto.conf.cmd is missing · 9390dff6
      Masahiro Yamada 提交于
      If include/config/auto.conf.cmd is lost for some reasons, it is not
      self-healing, so the top Makefile misses to run syncconfig.
      Move include/config/auto.conf.cmd to the target side.
      
      I used a pattern rule instead of a normal rule here although it is
      a bit gross.
      
      If the rule were written with a normal rule like this,
      
        include/config/auto.conf \
        include/config/auto.conf.cmd \
        include/config/tristate.conf: $(KCONFIG_CONFIG)
                $(Q)$(MAKE) -f $(srctree)/Makefile syncconfig
      
      ... syncconfig would be executed per target.
      
      Using a pattern rule makes sure that syncconfig is executed just once
      because Make assumes the recipe will create all of the targets.
      
      Here is a quote from the GNU Make manual [1]:
      
      "Pattern rules may have more than one target. Unlike normal rules,
      this does not act as many different rules with the same prerequisites
      and recipe. If a pattern rule has multiple targets, make knows that
      the rule's recipe is responsible for making all of the targets. The
      recipe is executed only once to make all the targets. When searching
      for a pattern rule to match a target, the target patterns of a rule
      other than the one that matches the target in need of a rule are
      incidental: make worries only about giving a recipe and prerequisites
      to the file presently in question. However, when this file's recipe is
      run, the other targets are marked as having been updated themselves."
      
      [1]: https://www.gnu.org/software/make/manual/html_node/Pattern-Intro.htmlSigned-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      9390dff6
    • M
      kbuild: simplify single target rules · 6b12de69
      Masahiro Yamada 提交于
      The dependency will be checked anyway after Kbuild descends into a
      sub-directory. Skip object/source dependency checks in top Makefile.
      
      VPATH can be simpler since the top Makefile no longer checks the
      presence of the source file, which is located in in the external
      module directory.
      
      One good thing is, it can compile an object from a generated source
      file.
      
        $ make crypto/rsapubkey.asn1.o
          ...
        ASN.1   crypto/rsapubkey.asn1.c
        CC      crypto/rsapubkey.asn1.o
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      6b12de69
    • M
      kbuild: remove empty rules for makefiles · b999923c
      Masahiro Yamada 提交于
      The previous commit made 'MAKEFLAGS += -rR' effective in the top
      Makefile regardless of O= option, GNU Make versions.
      
      The top Makefile does not need to cancel implicit rules for makefiles.
      
      There is still one place where an empty rule is useful. Since -rR is
      effective only after sub-make, GNU Make would try implicit rules to
      update the top Makefile. Although it is not a big overhead, cancel it
      just in case.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      b999923c
    • M
      kbuild: make -r/-R effective in top Makefile for old Make versions · 3812b8c5
      Masahiro Yamada 提交于
      Adding -rR to MAKEFLAGS is important because we do not want to
      be bothered by built-in implicit rules or variables.
      
      One problem that used to exist in older GNU Make versions is
      
        MAKEFLAGS += -rR
      
      ... does not become effective in the current Makefile. When you are
      building with O= option, it becomes effective in the top Makefile
      since it recurses via 'sub-make' target. Otherwise, the top Makefile
      tries implicit rules. That is why we explicitly add empty rules for
      Makefiles, but we often miss to do that.
      
      In fact, adding -d option to older GNU Make versions shows it is
      trying a bunch of implicit pattern rules.
      
       Considering target file `scripts/Makefile.kcov'.
        Looking for an implicit rule for `scripts/Makefile.kcov'.
        Trying pattern rule with stem `Makefile.kcov'.
        Trying implicit prerequisite `scripts/Makefile.kcov.o'.
        Trying pattern rule with stem `Makefile.kcov'.
        Trying implicit prerequisite `scripts/Makefile.kcov.c'.
        Trying pattern rule with stem `Makefile.kcov'.
        Trying implicit prerequisite `scripts/Makefile.kcov.cc'.
        Trying pattern rule with stem `Makefile.kcov'.
        Trying implicit prerequisite `scripts/Makefile.kcov.C'.
        ...
      
      This issue was fixed by GNU Make commit 58dae243526b ("[Savannah #20501]
      Handle adding -r/-R to MAKEFLAGS in the makefile"). So, it is no longer
      a problem if you use GNU Make 4.0 or later. However, older versions are
      still widely used.
      
      So, I decided to patch the kernel Makefile to invoke sub-make regardless
      of O= option. This will allow further cleanups.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      3812b8c5
    • M
      kbuild: move tools_silent to a more relevant place · f47a23ce
      Masahiro Yamada 提交于
      This would disturb the change the sub-make part. Move it near the
      tools/ target.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      f47a23ce
    • M
      kbuild: compute false-positive -Wmaybe-uninitialized cases in Kconfig · b303c6df
      Masahiro Yamada 提交于
      Since -Wmaybe-uninitialized was introduced by GCC 4.7, we have patched
      various false positives:
      
       - commit e74fc973 ("Turn off -Wmaybe-uninitialized when building
         with -Os") turned off this option for -Os.
      
       - commit 815eb71e ("Kbuild: disable 'maybe-uninitialized' warning
         for CONFIG_PROFILE_ALL_BRANCHES") turned off this option for
         CONFIG_PROFILE_ALL_BRANCHES
      
       - commit a76bcf55 ("Kbuild: enable -Wmaybe-uninitialized warning
         for "make W=1"") turned off this option for GCC < 4.9
         Arnd provided more explanation in https://lkml.org/lkml/2017/3/14/903
      
      I think this looks better by shifting the logic from Makefile to Kconfig.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/350Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: NNathan Chancellor <natechancellor@gmail.com>
      Tested-by: NNick Desaulniers <ndesaulniers@google.com>
      b303c6df
    • M
      kbuild: refactor cc-cross-prefix implementation · bd55f96f
      Masahiro Yamada 提交于
      - $(word 1, <text>) is equivalent to $(firstword <text>)
      
       - hardcode "gcc" instead of $(CC)
      
       - minimize the shell script part
      
      A little more notes in case $(filter-out -%, ...) is not clear.
      
      arch/mips/Makefile passes prefixes depending on the configuration.
      
      CROSS_COMPILE := $(call cc-cross-prefix, $(tool-archpref)-linux- \
          $(tool-archpref)-linux-gnu- $(tool-archpref)-unknown-linux-gnu-)
      
      In the Kconfig stage (e.g. when you run 'make defconfig'), neither
      CONFIG_32BIT nor CONFIG_64BIT is defined. So, $(tool-archpref) is
      empty. As a result, "-linux -linux-gnu- -unknown-linux-gnu" is passed
      into cc-cross-prefix. The command 'which' assumes arguments starting
      with a hyphen as command options, then emits the following messages:
      
        Illegal option -l
        Illegal option -l
        Illegal option -u
      
      I think it is strange to define CROSS_COMPILE depending on the CONFIG
      options since you need to feed $(CC) to Kconfig, but it is how MIPS
      Makefile currently works. Anyway, it would not hurt to filter-out
      invalid strings beforehand.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      bd55f96f
    • M
      kbuild: hardcode genksyms path and remove GENKSYMS variable · 88110713
      Masahiro Yamada 提交于
      The genksyms source was integrated into the kernel tree in 2003.
      
      I do not expect anybody still using the external /sbin/genksyms.
      Kbuild does not need to provide the ability to override GENKSYMS.
      
      Let's remove the GENKSYMS variable, and use the hardcoded path.
      
      Since it occurred in the pre-git era, I attached the commit message
      in case somebody is interested in the historical background.
      
        | Author: Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>
        | Date:   Wed Feb 19 04:17:28 2003 -0600
        |
        | kbuild: [PATCH] put genksyms in scripts dir
        |
        | This puts genksyms into scripts/genksyms/.
        |
        | genksyms used to be maintained externally, though the only possible user
        | was the kernel build. Moving it into the kernel sources makes it easier to
        | keep it uptodate, like for example updating it to generate linker scripts
        | directly instead of postprocessing the generated header file fragments
        | with sed, as we do currently.
        |
        | Also, genksyms does not handle __typeof__, which needs to be fixed since
        | some of the exported symbol in the kernel are defined using __typeof__.
        |
        | (Rusty Russell/me)
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      88110713
    • M
      scripts/gdb: refactor rules for symlink creation · b513adf4
      Masahiro Yamada 提交于
      gdb-scripts is not a real object, but (ab)used like a phony target.
      
      Rewrite the code in a more Kbuild-ish way. Add symlinks to extra-y
      and use if_changed.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: NKieran Bingham <kieran.bingham@ideasonboard.com>
      b513adf4
    • M
      kbuild: create symlink to vmlinux-gdb.py in scripts_gdb target · 8d2e5200
      Masahiro Yamada 提交于
      It is weird to create gdb stuff as a side-effect of vmlinux.
      
      Move it to a more relevant place.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: NKieran Bingham <kieran.bingham@ideasonboard.com>
      8d2e5200
    • M
      scripts/gdb: do not descend into scripts/gdb from scripts · 1e5ff84f
      Masahiro Yamada 提交于
      Currently, Kbuild descends from scripts/Makefile to scripts/gdb/Makefile
      just for creating symbolic links, but it does not need to do it so early.
      
      Merge the two descending paths to simplify the code.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: NKieran Bingham <kieran.bingham@ideasonboard.com>
      1e5ff84f
    • M
      kbuild: remove unimportant comments from ./Kbuild · 01d509a4
      Masahiro Yamada 提交于
      Every time we add/remove a target, we need to touch the header part,
      including renumbering. This is not so important information.
      
      Numbering targets is rather misleading because they are not necessarily
      generated in this order. For example, 1) and 2) can be executed
      simultaneously when the -j option is given.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: NKieran Bingham <kieran.bingham@ideasonboard.com>
      01d509a4
    • M
      scripts/gdb: delay generation of gdb constants.py · 67274c08
      Masahiro Yamada 提交于
      scripts/gdb/linux/constants.py is never used in the kernel build
      process. There is no good reason to create it so early.
      
      Get it out of the 'prepare' stage.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: NKieran Bingham <kieran.bingham@ideasonboard.com>
      67274c08
  3. 20 2月, 2019 6 次提交
  4. 19 2月, 2019 4 次提交
  5. 28 1月, 2019 15 次提交