18 Mar, 2019

1 commit


17 Mar, 2019

2 commits

  • Currently, every arch/*/include/uapi/asm/Kbuild explicitly includes
    the common Kbuild.asm file. Factor out the duplicated include directives
    to scripts/Makefile.asm-generic so that no architecture would opt out
    of the mandatory-y mechanism.

    um is not forced to include mandatory-y since it is a very exceptional
    case which does not support UAPI.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • During a simple no-op (nothing changed) build I saw 39 invocations of
    the C compiler with the argument "-print-file-name=include". We don't
    need to call the C compiler 39 times for this--one time will suffice.

    Let's change NOSTDINC_FLAGS to a simply expanded variable to avoid
    this since there doesn't appear to be any reason it should be
    recursively expanded.

    On my build this shaved ~400 ms off my "no-op" build.

    Note that the recursive expansion seems to date back to the (really
    old) commit e8f5bdb02ce0 ("[PATCH] Makefile include path ordering").
    It's a little unclear to me if the point of that patch was to switch
    the variable to be recursively expanded (which it did) or to avoid
    directly assigning to NOSTDINC_FLAGS (AKA to switch to +=) because
    someone else (out of tree?) was setting it. I presume later since if
    the only goal was to switch to recursive expansion the patch would
    have just removed the ":".

    Signed-off-by: Douglas Anderson
    Signed-off-by: Masahiro Yamada

    Douglas Anderson
     

14 Mar, 2019

1 commit

  • Since commit 3812b8c5c5d5 ("kbuild: make -r/-R effective in top
    Makefile for old Make versions"), make-kpkg is not working.

    make-kpkg directly includes the top Makefile of Linux kernel, and
    appends some debian_* targets.

    /usr/share/kernel-package/ruleset/kernel_version.mk:

    # Include the kernel makefile
    override dot-config := 1
    include Makefile
    dot-config := 1

    I did not know the kernel Makefile was used in that way, and it is
    hard to guarantee the behavior when the kernel Makefile is included
    by another Makefile from a different project.

    It looks like Debian Stretch stopped providing make-kpkg. Maybe it is
    obsolete and being replaced with 'make deb-pkg' etc. but still widely
    used.

    This commit adds a workaround; if the top Makefile is included by
    another Makefile, skip sub-make in order to make the main part visible.
    'MAKEFLAGS += -rR' does not become effective for GNU Make < 4.0, but
    Debian/Ubuntu is already using newer versions.

    The effect of this commit:

    Debian 8 (Jessie) : Fixed
    Debian 9 (Stretch) : make-kpkg (kernel-package) is not provided
    Ubuntu 14.04 LTS : NOT Fixed
    Ubuntu 16.04 LTS : Fixed
    Ubuntu 18.04 LTS : Fixed

    This commit cannot fix Ubuntu 14.04 because it installs GNU Make 3.81,
    but its support will end in Apr 2019, which is before the Linux v5.1
    release.

    I added warning so that nobody would try to include the top Makefile.

    Fixes: 3812b8c5c5d5 ("kbuild: make -r/-R effective in top Makefile for old Make versions")
    Reported-by: Liz Zhang
    Signed-off-by: Masahiro Yamada
    Tested-by: Lili Deng
    Cc: Manoj Srivastava

    Masahiro Yamada
     

11 Mar, 2019

1 commit

  • Pull Kbuild updates from Masahiro Yamada:

    - do not generate unneeded top-level built-in.a

    - let git ignore O= directory entirely

    - optimize scripts/kallsyms slightly

    - exclude DWARF info from *.s regardless of config options

    - fix GCC toolchain search path for Clang to prepare ld.lld support

    - do not generate modules.order when CONFIG_MODULES is disabled

    - simplify single target rules and remove VPATH for external module
    build

    - allow to add optional flags to dpkg-buildpackage when building
    deb-pkg

    - move some compiler option tests from Makefile to Kconfig

    - various Makefile cleanups

    * tag 'kbuild-v5.1' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (40 commits)
    kbuild: remove scripts/basic/% build target
    kbuild: use -Werror=implicit-... instead of -Werror-implicit-...
    kbuild: clean up scripts/gcc-version.sh
    kbuild: remove cc-version macro
    kbuild: update comment block of scripts/clang-version.sh
    kbuild: remove commented-out INITRD_COMPRESS
    kbuild: move -gsplit-dwarf, -gdwarf-4 option tests to Kconfig
    kbuild: [bin]deb-pkg: add DPKG_FLAGS variable
    kbuild: move ".config not found!" message from Kconfig to Makefile
    kbuild: invoke syncconfig if include/config/auto.conf.cmd is missing
    kbuild: simplify single target rules
    kbuild: remove empty rules for makefiles
    kbuild: make -r/-R effective in top Makefile for old Make versions
    kbuild: move tools_silent to a more relevant place
    kbuild: compute false-positive -Wmaybe-uninitialized cases in Kconfig
    kbuild: refactor cc-cross-prefix implementation
    kbuild: hardcode genksyms path and remove GENKSYMS variable
    scripts/gdb: refactor rules for symlink creation
    kbuild: create symlink to vmlinux-gdb.py in scripts_gdb target
    scripts/gdb: do not descend into scripts/gdb from scripts
    ...

    Linus Torvalds
     

07 Mar, 2019

1 commit

  • Pull driver core updates from Greg KH:
    "Here is the big driver core patchset for 5.1-rc1

    More patches than "normal" here this merge window, due to some work in
    the driver core by Alexander Duyck to rework the async probe
    functionality to work better for a number of devices, and independant
    work from Rafael for the device link functionality to make it work
    "correctly".

    Also in here is:

    - lots of BUS_ATTR() removals, the macro is about to go away

    - firmware test fixups

    - ihex fixups and simplification

    - component additions (also includes i915 patches)

    - lots of minor coding style fixups and cleanups.

    All of these have been in linux-next for a while with no reported
    issues"

    * tag 'driver-core-5.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (65 commits)
    driver core: platform: remove misleading err_alloc label
    platform: set of_node in platform_device_register_full()
    firmware: hardcode the debug message for -ENOENT
    driver core: Add missing description of new struct device_link field
    driver core: Fix PM-runtime for links added during consumer probe
    drivers/component: kerneldoc polish
    async: Add cmdline option to specify drivers to be async probed
    driver core: Fix possible supplier PM-usage counter imbalance
    PM-runtime: Fix __pm_runtime_set_status() race with runtime resume
    driver: platform: Support parsing GpioInt 0 in platform_get_irq()
    selftests: firmware: fix verify_reqs() return value
    Revert "selftests: firmware: remove use of non-standard diff -Z option"
    Revert "selftests: firmware: add CONFIG_FW_LOADER_USER_HELPER_FALLBACK to config"
    device: Fix comment for driver_data in struct device
    kernfs: Allocating memory for kernfs_iattrs with kmem_cache.
    sysfs: remove unused include of kernfs-internal.h
    driver core: Postpone DMA tear-down until after devres release
    driver core: Document limitation related to DL_FLAG_RPM_ACTIVE
    PM-runtime: Take suppliers into account in __pm_runtime_set_status()
    device.h: Add __cold to dev_ logging functions
    ...

    Linus Torvalds
     

05 Mar, 2019

1 commit

  • This build rule was introduced by commit cd05e6bdc600 ("[PATCH]
    kbuild: fix split-include dependency") to handle the dependency of
    scripts/basic/split-include.

    Now, fixdep is the only tool in scripts/basic/, and this rule is
    no longer used.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     

04 Mar, 2019

3 commits


28 Feb, 2019

1 commit


27 Feb, 2019

11 commits

  • 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: Masahiro Yamada

    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.html

    Signed-off-by: Masahiro Yamada

    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: Masahiro Yamada

    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: Masahiro Yamada

    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: Masahiro Yamada

    Masahiro Yamada
     
  • This would disturb the change the sub-make part. Move it near the
    tools/ target.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • Since -Wmaybe-uninitialized was introduced by GCC 4.7, we have patched
    various false positives:

    - commit e74fc973b6e5 ("Turn off -Wmaybe-uninitialized when building
    with -Os") turned off this option for -Os.

    - commit 815eb71e7149 ("Kbuild: disable 'maybe-uninitialized' warning
    for CONFIG_PROFILE_ALL_BRANCHES") turned off this option for
    CONFIG_PROFILE_ALL_BRANCHES

    - commit a76bcf557ef4 ("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/350
    Signed-off-by: Masahiro Yamada
    Reviewed-by: Nathan Chancellor
    Tested-by: Nick Desaulniers

    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
    | 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: Masahiro Yamada

    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: Masahiro Yamada
    Reviewed-by: Kieran Bingham

    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: Masahiro Yamada
    Reviewed-by: Kieran Bingham

    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: Masahiro Yamada
    Reviewed-by: Kieran Bingham

    Masahiro Yamada
     

25 Feb, 2019

1 commit


20 Feb, 2019

4 commits

  • Commit 06300b21f4c7 ("kbuild: support building individual files for
    external modules") introduced the '/' target. It works only for
    external modules to build all .o files, but skip the modpost stage.

    However, 'make /' looks a bit weird to me. 'make ./' is more sensible
    if you want to build all objects under the current directory, and it
    works as expected.

    Let's change '/' into a phony target that is an alias of './', but
    I may feel like deprecating it in the future.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • It is fine to set KBUILD_MODULES=1 when CONFIG_MODULES is disabled.
    It is actually how "make allnoconfig all" works.

    On the other hand, KBUILD_MODULES=1 is unneeded for the %.ko pattern.
    It is just a matter of whether modules.order is generated or not.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • This causes an issue when trying to build with `make LD=ld.lld` if
    ld.lld and the rest of your cross tools aren't in the same directory
    (ex. /usr/local/bin) (as is the case for Android's build system), as the
    GCC_TOOLCHAIN_DIR then gets set based on `which $(LD)` which will point
    where LLVM tools are, not GCC/binutils tools are located.

    Instead, select the GCC_TOOLCHAIN_DIR based on another tool provided by
    binutils for which LLVM does not provide a substitute for, such as
    elfedit.

    Fixes: 785f11aa595b ("kbuild: Add better clang cross build support")
    Link: https://github.com/ClangBuiltLinux/linux/issues/341
    Suggested-by: Nathan Chancellor
    Reviewed-by: Nathan Chancellor
    Tested-by: Nathan Chancellor
    Signed-off-by: Nick Desaulniers
    Signed-off-by: Masahiro Yamada

    Nick Desaulniers
     
  • Modern gcc adds view assignments, reset assertion checking in .loc
    directives and a couple more additional debug markers, which clutters
    the asm output unnecessarily:

    For example:

    bsp_resume:
    .LFB3466:
    .loc 1 1868 1 is_stmt 1 view -0
    .cfi_startproc
    .loc 1 1869 2 view .LVU73
    # arch/x86/kernel/cpu/common.c:1869: if (this_cpu->c_bsp_resume)
    .loc 1 1869 14 is_stmt 0 view .LVU74
    movq this_cpu(%rip), %rax # this_cpu, this_cpu
    movq 64(%rax), %rax # this_cpu.94_1->c_bsp_resume, _2
    # arch/x86/kernel/cpu/common.c:1869: if (this_cpu->c_bsp_resume)
    .loc 1 1869 5 view .LVU75
    testq %rax, %rax # _2
    je .L8 #,
    .loc 1 1870 3 is_stmt 1 view .LVU76
    movq $boot_cpu_data, %rdi #,
    jmp __x86_indirect_thunk_rax

    or
    .loc 2 57 9 view .LVU478
    .loc 2 57 9 view .LVU479
    .loc 2 57 9 view .LVU480
    .loc 2 57 9 view .LVU481
    .LBB1385:
    .LBB1383:
    .LBB1379:
    .LBB1377:
    .LBB1375:
    .loc 2 57 9 view .LVU482
    .loc 2 57 9 view .LVU483
    movl %edi, %edx # cpu, cpu
    .LVL87:
    .loc 2 57 9 is_stmt 0 view .LVU484

    That MOV in there is drowned in debugging information and latter makes
    it hard to follow the asm. And that DWARF info is not really needed for
    asm output staring.

    Disable the debug information generation which clutters the asm output
    unnecessarily:

    bsp_resume:
    # arch/x86/kernel/cpu/common.c:1869: if (this_cpu->c_bsp_resume)
    movq this_cpu(%rip), %rax # this_cpu, this_cpu
    movq 64(%rax), %rax # this_cpu.94_1->c_bsp_resume, _2
    # arch/x86/kernel/cpu/common.c:1869: if (this_cpu->c_bsp_resume)
    testq %rax, %rax # _2
    je .L8 #,
    # arch/x86/kernel/cpu/common.c:1870: this_cpu->c_bsp_resume(&boot_cpu_data);
    movq $boot_cpu_data, %rdi #,
    jmp __x86_indirect_thunk_rax
    .L8:
    # arch/x86/kernel/cpu/common.c:1871: }
    rep ret
    .size bsp_resume, .-bsp_resume

    [ bp: write commit message. ]

    Signed-off-by: Masahiro Yamada
    Signed-off-by: Borislav Petkov

    Masahiro Yamada
     

19 Feb, 2019

1 commit

  • When compiling into output directory using O=, many files
    created under KBUILD_OUTPUT that git considers
    as new ones; git clients, ex. "git gui" lists it, and it clutters
    file list making it difficult to see what was really changed

    Generate .gitignore in output directory that ignores all
    its content

    Signed-off-by: Vladimir Kondratiev
    Signed-off-by: Masahiro Yamada

    Vladimir Kondratiev
     

18 Feb, 2019

1 commit


11 Feb, 2019

2 commits


04 Feb, 2019

1 commit


28 Jan, 2019

3 commits

  • There is no build order among the following:
    prepare3
    outputmakefile
    asm-generic
    $(version_h)
    $(autoksyms_h)
    include/generated/utsrelease.h

    It is meaningless to insert the prepare2 target between the first
    three and the last three.

    The comment says, "prepare2 creates a makefile if using a separate
    output directory." Let me explain it more precisely. The prepare
    targets cannot be executed without the .config file. Because the
    configuration targets depend on the outputmakefile target, the
    generated makefile is already there before the parepare2 is run.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • The top Makefile does not need to export KBUILD_VMLINUX_INIT and
    KBUILD_VMLINUX_MAIN separately.

    Put every built-in.a into KBUILD_VMLINUX_OBJS. The order of
    $(head-y), $(init-y), $(core-y), ... is still retained.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • Linus Torvalds
     

22 Jan, 2019

1 commit


21 Jan, 2019

1 commit


17 Jan, 2019

1 commit

  • Commit c3ff2a5193fa ("powerpc/32: add stack protector support")
    caused kernel panic on PowerPC when an external module is used with
    CONFIG_STACKPROTECTOR because the 'prepare' target was not executed
    for the external module build.

    Commit e07db28eea38 ("kbuild: fix single target build for external
    module") turned it into a build error because the 'prepare' target is
    now executed but the 'prepare0' target is missing for the external
    module build.

    External module on arm/arm64 with CONFIG_STACKPROTECTOR_PER_TASK is
    also broken in the same way.

    Move 'PHONY += prepare0' to the common place. GNU Make is fine with
    missing rule for phony targets. I also removed the comment which is
    wrong irrespective of this commit.

    I minimize the change so it can be easily backported to 4.20.x

    To fix v4.20, please backport e07db28eea38 ("kbuild: fix single target
    build for external module"), and then this commit.

    Link: https://bugzilla.kernel.org/show_bug.cgi?id=201891
    Fixes: e07db28eea38 ("kbuild: fix single target build for external module")
    Fixes: c3ff2a5193fa ("powerpc/32: add stack protector support")
    Fixes: 189af4657186 ("ARM: smp: add support for per-task stack canaries")
    Fixes: 0a1213fa7432 ("arm64: enable per-task stack canaries")
    Cc: linux-stable # v4.20
    Reported-by: Samuel Holland
    Reported-by: Alexey Kardashevskiy
    Signed-off-by: Masahiro Yamada
    Acked-by: Ard Biesheuvel
    Tested-by: Alexey Kardashevskiy

    Masahiro Yamada
     

16 Jan, 2019

1 commit


14 Jan, 2019

1 commit