Eric Lee / smarc-fsl-linux-kernel

24 Feb, 2020

1 commit

  • 59e2355bd   kbuild: use -S instead of -E for precise cc-option test in Kconfig ... Browse Code »

    [ Upstream commit 3bed1b7b9d79ca40e41e3af130931a3225e951a3 ]

    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
    Signed-off-by: Sasha Levin

    Masahiro Yamada
     

14 Aug, 2019

1 commit

  • 75959d44f   kbuild: Fail if gold linker is detected ... Browse Code »

    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

  • e8de12fb7   kbuild: Check for unknown options with cc-option usage in Kconfig and clang ... Browse Code »

    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

  • 902a6898b   kbuild: terminate Kconfig when $(CC) or $(LD) is missing ... Browse Code »

    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

  • 59f53855b   gcc-plugins: test plugin support in Kconfig and clean up Makefile ... Browse Code »

    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