Skip to content
Snippets Groups Projects
  1. Sep 04, 2019
    • Masahiro Yamada's avatar
      kbuild: change *FLAGS_<basetarget>.o to take the path relative to $(obj) · 54b8ae66
      Masahiro Yamada authored
      
      Kbuild provides per-file compiler flag addition/removal:
      
        CFLAGS_<basetarget>.o
        CFLAGS_REMOVE_<basetarget>.o
        AFLAGS_<basetarget>.o
        AFLAGS_REMOVE_<basetarget>.o
        CPPFLAGS_<basetarget>.lds
        HOSTCFLAGS_<basetarget>.o
        HOSTCXXFLAGS_<basetarget>.o
      
      The <basetarget> is the filename of the target with its directory and
      suffix stripped.
      
      This syntax comes into a trouble when two files with the same basename
      appear in one Makefile, for example:
      
        obj-y += foo.o
        obj-y += dir/foo.o
        CFLAGS_foo.o := <some-flags>
      
      Here, the <some-flags> applies to both foo.o and dir/foo.o
      
      The real world problem is:
      
        scripts/kconfig/util.c
        scripts/kconfig/lxdialog/util.c
      
      Both files are compiled into scripts/kconfig/mconf, but only the
      latter should be given with the ncurses flags.
      
      It is more sensible to use the relative path to the Makefile, like this:
      
        obj-y += foo.o
        CFLAGS_foo.o := <some-flags>
        obj-y += dir/foo.o
        CFLAGS_dir/foo.o := <other-flags>
      
      At first, I attempted to replace $(basetarget) with $*. The $* variable
      is replaced with the stem ('%') part in a pattern rule. This works with
      most of cases, but does not for explicit rules.
      
      For example, arch/ia64/lib/Makefile reuses rule_as_o_S in its own
      explicit rules, so $* will be empty, resulting in ignoring the per-file
      AFLAGS.
      
      I introduced a new variable, target-stem, which can be used also from
      explicit rules.
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: default avatarMarc Zyngier <maz@kernel.org>
      54b8ae66
    • Masahiro Yamada's avatar
      kbuild: add $(BASH) to run scripts with bash-extension · 858805b3
      Masahiro Yamada authored
      
      CONFIG_SHELL falls back to sh when bash is not installed on the system,
      but nobody is testing such a case since bash is usually installed.
      So, shell scripts invoked by CONFIG_SHELL are only tested with bash.
      
      It makes it difficult to test whether the hashbang #!/bin/sh is real.
      For example, #!/bin/sh in arch/powerpc/kernel/prom_init_check.sh is
      false. (I fixed it up)
      
      Besides, some shell scripts invoked by CONFIG_SHELL use bash-extension
      and #!/bin/bash is specified as the hashbang, while CONFIG_SHELL may
      not always be set to bash.
      
      Probably, the right thing to do is to introduce BASH, which is bash by
      default, and always set CONFIG_SHELL to sh. Replace $(CONFIG_SHELL)
      with $(BASH) for bash scripts.
      
      If somebody tries to add bash-extension to a #!/bin/sh script, it will
      be caught in testing because /bin/sh is a symlink to dash on some major
      distributions.
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      858805b3
  2. Aug 21, 2019
  3. Aug 14, 2019
  4. Aug 13, 2019
    • Masahiro Yamada's avatar
      kbuild: move flex and bison rules to Makefile.host · cf8dfd15
      Masahiro Yamada authored
      
      Flex and bison are used for kconfig, dtc, genksyms, all of which are
      host programs. I never imagine the kernel embeds a parser or a lexer.
      
      Move the flex and bison rules to scripts/Makefile.host. This file is
      included only when hostprogs-y etc. is present in the Makefile in the
      directory. So, parsing these rules are skipped in most of directories.
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      cf8dfd15
    • Masahiro Yamada's avatar
      kbuild: make bison create C file and header in a single pattern rule · 6ba7dc66
      Masahiro Yamada authored
      We generally expect bison to create not only a C file, but also a
      header, which will be included from the lexer.
      
      Currently, Kbuild generates them in separate rules. So, for instance,
      when building Kconfig, you will notice bison is invoked twice:
      
        HOSTCC  scripts/kconfig/conf.o
        HOSTCC  scripts/kconfig/confdata.o
        HOSTCC  scripts/kconfig/expr.o
        LEX     scripts/kconfig/lexer.lex.c
        YACC    scripts/kconfig/parser.tab.h
        HOSTCC  scripts/kconfig/lexer.lex.o
        YACC    scripts/kconfig/parser.tab.c
        HOSTCC  scripts/kconfig/parser.tab.o
        HOSTCC  scripts/kconfig/preprocess.o
        HOSTCC  scripts/kconfig/symbol.o
        HOSTLD  scripts/kconfig/conf
      
      Make handles such cases nicely in pattern rules [1]. Merge the two
      rules so that one invokcation of bison can generate both of them.
      
        HOSTCC  scripts/kconfig/conf.o
        HOSTCC  scripts/kconfig/confdata.o
        HOSTCC  scripts/kconfig/expr.o
        LEX     scripts/kconfig/lexer.lex.c
        YACC    scripts/kconfig/parser.tab.[ch]
        HOSTCC  scripts/kconfig/lexer.lex.o
        HOSTCC  scripts/kconfig/parser.tab.o
        HOSTCC  scripts/kconfig/preprocess.o
        HOSTCC  scripts/kconfig/symbol.o
        HOSTLD  scripts/kconfig/conf
      
      [1] Pattern rule
      
      GNU Make manual says:
      "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."
      
      https://www.gnu.org/software/make/manual/html_node/Pattern-Intro.html
      
      
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      6ba7dc66
  5. Jul 27, 2019
  6. Jul 17, 2019
  7. Jul 10, 2019
  8. Jul 09, 2019
    • Masahiro Yamada's avatar
      kbuild: support header-test-pattern-y · 1e21cbfa
      Masahiro Yamada authored
      
      In my view, most of headers can be self-contained. So, it would be
      tedious to add every header to header-test-y explicitly. We usually
      end up with "all headers with some exceptions".
      
      There are two types in exceptions:
      
      [1] headers that are never compiled as standalone units
      
        For examples, include/linux/compiler-gcc.h is not intended for
        direct inclusion. We should always exclude such ones.
      
      [2] headers that are conditionally compiled as standalone units
      
        Some headers can be compiled only for particular architectures.
        For example, include/linux/arm-cci.h can be compiled only for
        arm/arm64 because it requires <asm/arm-cci.h> to exist.
        Clang can compile include/soc/nps/mtm.h only for arc because
        it contains an arch-specific register in inline assembler.
      
      So, you can write Makefile like this:
      
        header-test-                += linux/compiler-gcc.h
        header-test-$(CONFIG_ARM)   += linux/arm-cci.h
        header-test-$(CONFIG_ARM64) += linux/arm-cci.h
        header-test-$(CONFIG_ARC)   += soc/nps/mtm.h
      
      The new syntax header-test-pattern-y will be useful to specify
      "the rest".
      
      The typical usage is like this:
      
        header-test-pattern-y += */*.h
      
      This will add all the headers in sub-directories to the test coverage,
      excluding $(header-test-). In this regards, header-test-pattern-y
      behaves like a weaker variant of header-test-y.
      
      Caveat:
      The patterns in header-test-pattern-y are prefixed with $(srctree)/$(src)/
      but not $(objtree)/$(obj)/. Stale generated headers are often left over
      when you traverse the git history without cleaning. Wildcard patterns for
      $(objtree) may match to stale headers, which could fail to compile.
      One pitfall is $(srctree)/$(src)/ and $(objtree)/$(obj)/ point to the
      same directory for in-tree building. So, header-test-pattern-y should
      be used with care since it can potentially match to stale headers.
      
      Caveat2:
      You could use wildcard for header-test-. For example,
      
        header-test- += asm-generic/%
      
      ... will exclude headers in asm-generic directory. Unfortunately, the
      wildcard character is '%' instead of '*' here because this is evaluated
      by $(filter-out ...) whereas header-test-pattern-y is evaluated by
      $(wildcard ...). This is a kludge, but seems useful in some places...
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Tested-by: default avatarJani Nikula <jani.nikula@intel.com>
      1e21cbfa
    • Masahiro Yamada's avatar
      kbuild: do not create wrappers for header-test-y · c93a0368
      Masahiro Yamada authored
      
      header-test-y does not work with headers in sub-directories.
      
      For example, you may want to write a Makefile, like this:
      
      include/linux/Kbuild:
      
        header-test-y += mtd/nand.h
      
      This entry will create a wrapper include/linux/mtd/nand.hdrtest.c
      with the following content:
      
        #include "mtd/nand.h"
      
      To make this work, we need to add $(srctree)/include/linux to the
      header search path. It would be tedious to add ccflags-y.
      
      Instead, we could change the *.hdrtest.c rule to wrap:
      
        #include "nand.h"
      
      This works for in-tree build since #include "..." searches in the
      relative path from the header with this directive. For O=... build,
      we need to add $(srctree)/include/linux/mtd to the header search path,
      which will be even more tedious.
      
      After all, I thought it would be handier to compile headers directly
      without creating wrappers.
      
      I added a new build rule to compile %.h into %.h.s
      
      The target is %.h.s instead of %.h.o because it is slightly faster.
      Also, as for GCC, an empty assembly is smaller than an empty object.
      
      I wrote the build rule:
      
        $(CC) $(c_flags) -S -o $@ -x c /dev/null -include $<
      
      instead of:
      
        $(CC) $(c_flags) -S -o $@ -x c $<
      
      Both work fine with GCC, but the latter is bad for Clang.
      
      This comes down to the difference in the -Wunused-function policy.
      GCC does not warn about unused 'static inline' functions at all.
      Clang does not warn about the ones in included headers, but does
      about the ones in the source. So, we should handle headers as
      headers, not as source files.
      
      In fact, this has been hidden since commit abb2ea7d ("compiler,
      clang: suppress warning for unused static inline functions"), but we
      should not rely on that.
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: default avatarJani Nikula <jani.nikula@intel.com>
      Tested-by: default avatarJani Nikula <jani.nikula@intel.com>
      c93a0368
  9. Jun 15, 2019
  10. May 22, 2019
  11. May 18, 2019
  12. Apr 02, 2019
    • Masahiro Yamada's avatar
      kbuild: use $(srctree) instead of KBUILD_SRC to check out-of-tree build · a9a49c2a
      Masahiro Yamada authored
      
      KBUILD_SRC was conventionally used for some different purposes:
       [1] To remember the source tree path
       [2] As a flag to check if sub-make is already done
       [3] As a flag to check if Kbuild runs out of tree
      
      For [1], we do not need to remember it because the top Makefile
      can compute it by $(realpath $(dir $(lastword $(MAKEFILE_LIST))))
      
      [2] has been replaced with self-commenting 'sub_make_done'.
      
      For [3], we can distinguish in-tree/out-of-tree by comparing
      $(srctree) and '.'
      
      This commit converts [3] to prepare for the KBUILD_SRC removal.
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      a9a49c2a
  13. Mar 13, 2019
  14. Jan 28, 2019
  15. Jan 06, 2019
  16. Dec 13, 2018
    • Rob Herring's avatar
      kbuild: Add support for DT binding schema checks · 4f0e3a57
      Rob Herring authored
      
      This adds the build infrastructure for checking DT binding schema
      documents and validating dts files using the binding schema.
      
      Check DT binding schema documents:
      make dt_binding_check
      
      Build dts files and check using DT binding schema:
      make dtbs_check
      
      Optionally, DT_SCHEMA_FILES can be passed in with a schema file(s) to
      use for validation. This makes it easier to find and fix errors
      generated by a specific schema.
      
      Currently, the validation targets are separate from a normal build to
      avoid a hard dependency on the external DT schema project and because
      there are lots of warnings generated.
      
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Michal Marek <michal.lkml@markovi.net>
      Cc: linux-doc@vger.kernel.org
      Cc: devicetree@vger.kernel.org
      Cc: linux-kbuild@vger.kernel.org
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      4f0e3a57
  17. Dec 01, 2018
  18. Nov 30, 2018
  19. Oct 02, 2018
    • Rob Herring's avatar
      kbuild: consolidate Devicetree dtb build rules · 37c8a5fa
      Rob Herring authored
      
      There is nothing arch specific about building dtb files other than their
      location under /arch/*/boot/dts/. Keeping each arch aligned is a pain.
      The dependencies and supported targets are all slightly different.
      Also, a cross-compiler for each arch is needed, but really the host
      compiler preprocessor is perfectly fine for building dtbs. Move the
      build rules to a common location and remove the arch specific ones. This
      is done in a single step to avoid warnings about overriding rules.
      
      The build dependencies had been a mixture of 'scripts' and/or 'prepare'.
      These pull in several dependencies some of which need a target compiler
      (specifically devicetable-offsets.h) and aren't needed to build dtbs.
      All that is really needed is dtc, so adjust the dependencies to only be
      dtc.
      
      This change enables support 'dtbs_install' on some arches which were
      missing the target.
      
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Acked-by: default avatarPaul Burton <paul.burton@mips.com>
      Acked-by: default avatarLey Foon Tan <ley.foon.tan@intel.com>
      Acked-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Michal Marek <michal.lkml@markovi.net>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: linux-kbuild@vger.kernel.org
      Cc: linux-snps-arc@lists.infradead.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: uclinux-h8-devel@lists.sourceforge.jp
      Cc: linux-mips@linux-mips.org
      Cc: nios2-dev@lists.rocketboards.org
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: linux-xtensa@linux-xtensa.org
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      37c8a5fa
  20. Aug 23, 2018
  21. Jul 28, 2018
  22. Jul 18, 2018
  23. May 15, 2018
  24. May 05, 2018
  25. Apr 07, 2018
    • Masahiro Yamada's avatar
      kbuild: mark $(targets) as .SECONDARY and remove .PRECIOUS markers · 54a702f7
      Masahiro Yamada authored
      
      GNU Make automatically deletes intermediate files that are updated
      in a chain of pattern rules.
      
      Example 1) %.dtb.o <- %.dtb.S <- %.dtb <- %.dts
      Example 2) %.o <- %.c <- %.c_shipped
      
      A couple of makefiles mark such targets as .PRECIOUS to prevent Make
      from deleting them, but the correct way is to use .SECONDARY.
      
        .SECONDARY
          Prerequisites of this special target are treated as intermediate
          files but are never automatically deleted.
      
        .PRECIOUS
          When make is interrupted during execution, it may delete the target
          file it is updating if the file was modified since make started.
          If you mark the file as precious, make will never delete the file
          if interrupted.
      
      Both can avoid deletion of intermediate files, but the difference is
      the behavior when Make is interrupted; .SECONDARY deletes the target,
      but .PRECIOUS does not.
      
      The use of .PRECIOUS is relatively rare since we do not want to keep
      partially constructed (possibly corrupted) targets.
      
      Another difference is that .PRECIOUS works with pattern rules whereas
      .SECONDARY does not.
      
        .PRECIOUS: $(obj)/%.lex.c
      
      works, but
      
        .SECONDARY: $(obj)/%.lex.c
      
      has no effect.  However, for the reason above, I do not want to use
      .PRECIOUS which could cause obscure build breakage.
      
      The targets specified as .SECONDARY must be explicit.  $(targets)
      contains all targets that need to include .*.cmd files.  So, the
      intermediates you want to keep are mostly in there.  Therefore, mark
      $(targets) as .SECONDARY.  It means primary targets are also marked
      as .SECONDARY, but I do not see any drawback for this.
      
      I replaced some .SECONDARY / .PRECIOUS markers with 'targets'.  This
      will make Kbuild search for non-existing .*.cmd files, but this is
      not a noticeable performance issue.
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: default avatarFrank Rowand <frowand.list@gmail.com>
      Acked-by: default avatarIngo Molnar <mingo@kernel.org>
      54a702f7
    • Masahiro Yamada's avatar
      kbuild: add %.dtb.S and %.dtb to 'targets' automatically · a7f92419
      Masahiro Yamada authored
      
      Another common pattern that consists of chained commands is to compile
      a DTB as binary data into the kernel image or a module.  It is used in
      several places in the source tree.  Support it in the core Makefile.
      
      $(call if_changed,dt_S_dtb) is more suitable than $(call cmd,dt_S_dtb)
      in case cmd_dt_S_dtb is changed in the future.
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: default avatarFrank Rowand <frowand.list@gmail.com>
      a7f92419
    • Masahiro Yamada's avatar
      genksyms: generate lexer and parser during build instead of shipping · 833e6224
      Masahiro Yamada authored
      
      Now that the kernel build supports flex and bison, remove the _shipped
      files and generate them during the build instead.
      
      There are no more shipped lexer and parser, so I ripped off the rules
      in scripts/Malefile.lib that were used for REGENERATE_PARSERS.
      
      The genksyms parser has ambiguous grammar, which would emit warnings:
      
       scripts/genksyms/parse.y: warning: 9 shift/reduce conflicts [-Wconflicts-sr]
       scripts/genksyms/parse.y: warning: 5 reduce/reduce conflicts [-Wconflicts-rr]
      
      They are normally suppressed, but displayed when W=1 is given.
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      833e6224
  26. Mar 31, 2018
    • Masahiro Yamada's avatar
      kbuild: get <linux/compiler_types.h> out of <linux/kconfig.h> · a95b37e2
      Masahiro Yamada authored
      
      Since commit 28128c61 ("kconfig.h: Include compiler types to avoid
      missed struct attributes"), <linux/kconfig.h> pulls in kernel-space
      headers to unrelated places.
      
      Commit 0f9da844 ("MIPS: boot: Define __ASSEMBLY__ for its.S build")
      suppress the build error by defining __ASSEMBLY__, but ITS (i.e. DTS)
      is not assembly, and should not include <linux/compiler_types.h> in the
      first place.
      
      Looking at arch/s390/tools/Makefile, host programs gen_facilities and
      gen_opcode_table now pull in <linux/compiler_types.h> as well.
      
      The motivation for that commit was to define necessary attributes
      before any struct is defined.  Obviously, this happens only in C.
      
      It is enough to include <linux/compiler_types.h> only when compiling
      C files, and only when compiling kernel space.  Move the include to
      c_flags.
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      a95b37e2
Loading