02 Feb, 2020

1 commit

  • Pull Kbuild updates from Masahiro Yamada:

    - detect missing include guard in UAPI headers

    - do not create orphan built-in.a or obj-y objects

    - generate modules.builtin more simply, and drop tristate.conf

    - simplify built-in initramfs creation

    - make linux-headers deb package thinner

    - optimize the deb package build script

    - misc cleanups

    * tag 'kbuild-v5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (34 commits)
    builddeb: split libc headers deployment out into a function
    builddeb: split kernel headers deployment out into a function
    builddeb: remove redundant make for ARCH=um
    builddeb: avoid invoking sub-shells where possible
    builddeb: remove redundant $objtree/
    builddeb: match temporary directory name to the package name
    builddeb: remove unneeded files in hdrobjfiles for headers package
    kbuild: use -S instead of -E for precise cc-option test in Kconfig
    builddeb: allow selection of .deb compressor
    kbuild: remove 'Building modules, stage 2.' log
    kbuild: remove *.tmp file when filechk fails
    kbuild: remove PYTHON2 variable
    modpost: assume STT_SPARC_REGISTER is defined
    gen_initramfs.sh: remove intermediate cpio_list on errors
    initramfs: refactor the initramfs build rules
    gen_initramfs.sh: always output cpio even without -o option
    initramfs: add default_cpio_list, and delete -d option support
    initramfs: generate dependency list and cpio at the same time
    initramfs: specify $(src)/gen_initramfs.sh as a prerequisite in Makefile
    initramfs: make initramfs compression choice non-optional
    ...

    Linus Torvalds
     

22 Jan, 2020

1 commit

  • Currently, -E (stop after the preprocessing stage) is used to check
    whether the given compiler flag is supported.

    While it is faster than -S (or -c), it can be false-positive. You need
    to run the compilation proper to check the flag more precisely.

    For example, -E and -S disagree about the support of
    "--param asan-instrument-allocas=1".

    $ gcc -Werror --param asan-instrument-allocas=1 -E -x c /dev/null -o /dev/null
    $ echo $?
    0

    $ gcc -Werror --param asan-instrument-allocas=1 -S -x c /dev/null -o /dev/null
    cc1: error: invalid --param name ‘asan-instrument-allocas’; did you mean ‘asan-instrument-writes’?
    $ echo $?
    1

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     

15 Jan, 2020

1 commit

  • Similar to 'cc-option' or 'ld-option', it is occasionally necessary to
    check whether the assembler supports certain ISA extensions. In the
    arm64 code we currently do this in Makefile with an additional define:

    lseinstr := $(call as-instr,.arch_extension lse,-DCONFIG_AS_LSE=1)

    Add the 'as-instr' option so that it can be used in Kconfig directly:

    def_bool $(as-instr,.arch_extension lse)

    Acked-by: Masahiro Yamada
    Reviewed-by: Vladimir Murzin
    Tested-by: Vladimir Murzin
    Signed-off-by: Catalin Marinas
    Signed-off-by: Will Deacon

    Catalin Marinas
     

14 Aug, 2019

1 commit

  • The gold linker has known issues of failing the build both in random and in
    predictible ways:

    - The x86/X32 VDSO build fails with:

    arch/x86/entry/vdso/vclock_gettime-x32.o:vclock_gettime.c:function do_hres:
    error: relocation overflow: reference to 'hvclock_page'

    That's a known issue for years and the usual workaround is to disable
    CONFIG_X86_32

    - A recent build failure is caused by turning a relocation into an
    absolute one for unknown reasons. See link below.

    - There are a couple of gold workarounds applied already, but reports
    about broken builds with ld.gold keep coming in on a regular base and in
    most cases the root cause is unclear.

    In context of the most recent fail H.J. stated:

    "Since building a workable kernel for different kernel configurations
    isn't a requirement for gold, I don't recommend gold for kernel."

    So instead of dealing with attempts to duct tape gold support without
    understanding the root cause and without support from the gold folks, fail
    the build when gold is detected.

    Signed-off-by: Thomas Gleixner
    Acked-by: Peter Zijlstra (Intel)
    Acked-by: Ingo Molnar
    Link: https://lore.kernel.org/r/CAMe9rOqMqkQ0LNpm25yE_Yt0FKp05WmHOrwc0aRDb53miFKM+w@mail.gmail.com
    Reviewed-by: Nathan Chancellor
    Tested-by: Nathan Chancellor
    Signed-off-by: Masahiro Yamada

    Thomas Gleixner
     

31 Jul, 2019

1 commit

  • If the particular version of clang a user has doesn't enable
    -Werror=unknown-warning-option by default, even though it is the
    default[1], then make sure to pass the option to the Kconfig cc-option
    command so that testing options from Kconfig files works properly.
    Otherwise, depending on the default values setup in the clang toolchain
    we will silently assume options such as -Wmaybe-uninitialized are
    supported by clang, when they really aren't.

    A compilation issue only started happening for me once commit
    589834b3a009 ("kbuild: Add -Werror=unknown-warning-option to
    CLANG_FLAGS") was applied on top of commit b303c6df80c9 ("kbuild:
    compute false-positive -Wmaybe-uninitialized cases in Kconfig"). This
    leads kbuild to try and test for the existence of the
    -Wmaybe-uninitialized flag with the cc-option command in
    scripts/Kconfig.include, and it doesn't see an error returned from the
    option test so it sets the config value to Y. Then the Makefile tries to
    pass the unknown option on the command line and
    -Werror=unknown-warning-option catches the invalid option and breaks the
    build. Before commit 589834b3a009 ("kbuild: Add
    -Werror=unknown-warning-option to CLANG_FLAGS") the build works fine,
    but any cc-option test of a warning option in Kconfig files silently
    evaluates to true, even if the warning option flag isn't supported on
    clang.

    Note: This doesn't change cc-option usages in Makefiles because those
    use a different rule that includes KBUILD_CFLAGS by default (see the
    __cc-option command in scripts/Kbuild.incluide). The KBUILD_CFLAGS
    variable already has the -Werror=unknown-warning-option flag set. Thanks
    to Doug for pointing out the different rule.

    [1] https://clang.llvm.org/docs/DiagnosticsReference.html#wunknown-warning-option
    Cc: Peter Smith
    Cc: Nick Desaulniers
    Cc: Douglas Anderson
    Signed-off-by: Stephen Boyd
    Reviewed-by: Nathan Chancellor
    Signed-off-by: Masahiro Yamada

    Stephen Boyd
     

21 May, 2019

1 commit


18 May, 2019

1 commit

  • If the compiler specified by $(CC) is not present, the Kconfig stage
    sprinkles 'not found' messages, then succeeds.

    $ make CROSS_COMPILE=foo defconfig
    /bin/sh: 1: foogcc: not found
    /bin/sh: 1: foogcc: not found
    *** Default configuration is based on 'x86_64_defconfig'
    ./scripts/gcc-version.sh: 17: ./scripts/gcc-version.sh: foogcc: not found
    ./scripts/gcc-version.sh: 18: ./scripts/gcc-version.sh: foogcc: not found
    ./scripts/gcc-version.sh: 19: ./scripts/gcc-version.sh: foogcc: not found
    ./scripts/gcc-version.sh: 17: ./scripts/gcc-version.sh: foogcc: not found
    ./scripts/gcc-version.sh: 18: ./scripts/gcc-version.sh: foogcc: not found
    ./scripts/gcc-version.sh: 19: ./scripts/gcc-version.sh: foogcc: not found
    ./scripts/clang-version.sh: 11: ./scripts/clang-version.sh: foogcc: not found
    ./scripts/gcc-plugin.sh: 11: ./scripts/gcc-plugin.sh: foogcc: not found
    init/Kconfig:16:warning: 'GCC_VERSION': number is invalid
    #
    # configuration written to .config
    #

    Terminate parsing files immediately if $(CC) or $(LD) is not found.
    "make *config" will fail more nicely.

    $ make CROSS_COMPILE=foo defconfig
    *** Default configuration is based on 'x86_64_defconfig'
    scripts/Kconfig.include:34: compiler 'foogcc' not found
    make[1]: *** [scripts/kconfig/Makefile;82: defconfig] Error 1
    make: *** [Makefile;557: defconfig] Error 2

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     

04 Mar, 2019

1 commit


11 Jun, 2018

1 commit

  • Run scripts/gcc-plugin.sh from Kconfig so that users can enable
    GCC_PLUGINS only when the compiler supports building plugins.

    Kconfig defines a new symbol, PLUGIN_HOSTCC. This will contain
    the compiler (g++ or gcc) used for building plugins, or empty
    if the plugin can not be supported at all.

    This allows us to remove all ugly testing in Makefile.gcc-plugins.

    Signed-off-by: Masahiro Yamada
    Acked-by: Kees Cook

    Masahiro Yamada
     

29 May, 2018

1 commit