kbuild: add dummy toolchains to enable all cc-option etc. in Kconfig
Staring v4.18, Kconfig evaluates compiler capabilities, and hides CONFIG
options your compiler does not support. This works well if you configure
and build the kernel on the same host machine.
It is inconvenient if you prepare the .config that is carried to a
different build environment (typically this happens when you package
the kernel for distros) because using a different compiler potentially
produces different CONFIG options than the real build environment.
So, you probably want to make as many options visible as possible.
In other words, you need to create a super-set of CONFIG options that
cover any build environment. If some of the CONFIG options turned out
to be unsupported on the build machine, they are automatically disabled
by the nature of Kconfig.
However, it is not feasible to get a full-featured compiler for every
arch.
This issue was discussed here:
https://lkml.org/lkml/2019/12/9/620
Other than distros, savedefconfig is also a problem. Some arch sub-systems
periodically resync defconfig files. If you use a less-capable compiler
for savedefconfig, options that do not meet 'depends on $(cc-option,...)'
will be forcibly disabled. So, 'make defconfig && make savedefconfig'
may silently change the behavior.
This commit adds a set of dummy toolchains that pretend to support any
feature.
Most of compiler features are tested by cc-option, which simply checks
the exit code of $(CC). The dummy tools are shell scripts that always
exit with 0. So, $(cc-option, ...) is evaluated as 'y'.
There are more complicated checks such as:
scripts/gcc-x86_{32,64}-has-stack-protector.sh
scripts/gcc-plugin.sh
scripts/tools-support-relr.sh
scripts/dummy-tools/gcc passes all checks.
From the top directory of the source tree, you can do:
$ make CROSS_COMPILE=scripts/dummy-tools/ oldconfig
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Tested-by: Jeremy Cline <jcline@redhat.com>
2020-04-07 15:53:52 +00:00
|
|
|
#!/bin/sh
|
|
|
|
# SPDX-License-Identifier: GPL-2.0-only
|
|
|
|
#
|
|
|
|
# Staring v4.18, Kconfig evaluates compiler capabilities, and hides CONFIG
|
|
|
|
# options your compiler does not support. This works well if you configure and
|
|
|
|
# build the kernel on the same host machine.
|
|
|
|
#
|
|
|
|
# It is inconvenient if you prepare the .config that is carried to a different
|
|
|
|
# build environment (typically this happens when you package the kernel for
|
|
|
|
# distros) because using a different compiler potentially produces different
|
|
|
|
# CONFIG options than the real build environment. So, you probably want to make
|
|
|
|
# as many options visible as possible. In other words, you need to create a
|
|
|
|
# super-set of CONFIG options that cover any build environment. If some of the
|
|
|
|
# CONFIG options turned out to be unsupported on the build machine, they are
|
|
|
|
# automatically disabled by the nature of Kconfig.
|
|
|
|
#
|
|
|
|
# However, it is not feasible to get a full-featured compiler for every arch.
|
|
|
|
# Hence these dummy toolchains to make all compiler tests pass.
|
|
|
|
#
|
|
|
|
# Usage:
|
|
|
|
#
|
|
|
|
# From the top directory of the source tree, run
|
|
|
|
#
|
|
|
|
# $ make CROSS_COMPILE=scripts/dummy-tools/ oldconfig
|
|
|
|
#
|
|
|
|
# Most of compiler features are tested by cc-option, which simply checks the
|
|
|
|
# exit code of $(CC). This script does nothing and just exits with 0 in most
|
|
|
|
# cases. So, $(cc-option, ...) is evaluated as 'y'.
|
|
|
|
#
|
|
|
|
# This scripts caters to more checks; handle --version and pre-process __GNUC__
|
|
|
|
# etc. to pretend to be GCC, and also do right things to satisfy some scripts.
|
|
|
|
|
|
|
|
# Check if the first parameter appears in the rest. Succeeds if found.
|
|
|
|
# This helper is useful if a particular option was passed to this script.
|
|
|
|
# Typically used like this:
|
|
|
|
# arg_contain <word-you-are-searching-for> "$@"
|
|
|
|
arg_contain ()
|
|
|
|
{
|
|
|
|
search="$1"
|
|
|
|
shift
|
|
|
|
|
|
|
|
while [ $# -gt 0 ]
|
|
|
|
do
|
|
|
|
if [ "$search" = "$1" ]; then
|
|
|
|
return 0
|
|
|
|
fi
|
|
|
|
shift
|
|
|
|
done
|
|
|
|
|
|
|
|
return 1
|
|
|
|
}
|
|
|
|
|
|
|
|
# To set CONFIG_CC_IS_GCC=y
|
|
|
|
if arg_contain --version "$@"; then
|
|
|
|
echo "gcc (scripts/dummy-tools/gcc)"
|
|
|
|
exit 0
|
|
|
|
fi
|
|
|
|
|
|
|
|
if arg_contain -E "$@"; then
|
2021-03-09 16:25:45 +00:00
|
|
|
# For scripts/cc-version.sh; This emulates GCC 20.0.0
|
kbuild: add dummy toolchains to enable all cc-option etc. in Kconfig
Staring v4.18, Kconfig evaluates compiler capabilities, and hides CONFIG
options your compiler does not support. This works well if you configure
and build the kernel on the same host machine.
It is inconvenient if you prepare the .config that is carried to a
different build environment (typically this happens when you package
the kernel for distros) because using a different compiler potentially
produces different CONFIG options than the real build environment.
So, you probably want to make as many options visible as possible.
In other words, you need to create a super-set of CONFIG options that
cover any build environment. If some of the CONFIG options turned out
to be unsupported on the build machine, they are automatically disabled
by the nature of Kconfig.
However, it is not feasible to get a full-featured compiler for every
arch.
This issue was discussed here:
https://lkml.org/lkml/2019/12/9/620
Other than distros, savedefconfig is also a problem. Some arch sub-systems
periodically resync defconfig files. If you use a less-capable compiler
for savedefconfig, options that do not meet 'depends on $(cc-option,...)'
will be forcibly disabled. So, 'make defconfig && make savedefconfig'
may silently change the behavior.
This commit adds a set of dummy toolchains that pretend to support any
feature.
Most of compiler features are tested by cc-option, which simply checks
the exit code of $(CC). The dummy tools are shell scripts that always
exit with 0. So, $(cc-option, ...) is evaluated as 'y'.
There are more complicated checks such as:
scripts/gcc-x86_{32,64}-has-stack-protector.sh
scripts/gcc-plugin.sh
scripts/tools-support-relr.sh
scripts/dummy-tools/gcc passes all checks.
From the top directory of the source tree, you can do:
$ make CROSS_COMPILE=scripts/dummy-tools/ oldconfig
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Tested-by: Jeremy Cline <jcline@redhat.com>
2020-04-07 15:53:52 +00:00
|
|
|
if arg_contain - "$@"; then
|
2022-08-10 09:26:03 +00:00
|
|
|
sed -n '/^GCC/{s/__GNUC__/20/; s/__GNUC_MINOR__/0/; s/__GNUC_PATCHLEVEL__/0/; p;}; s/__LONG_DOUBLE_128__/1/ p'
|
kbuild: add dummy toolchains to enable all cc-option etc. in Kconfig
Staring v4.18, Kconfig evaluates compiler capabilities, and hides CONFIG
options your compiler does not support. This works well if you configure
and build the kernel on the same host machine.
It is inconvenient if you prepare the .config that is carried to a
different build environment (typically this happens when you package
the kernel for distros) because using a different compiler potentially
produces different CONFIG options than the real build environment.
So, you probably want to make as many options visible as possible.
In other words, you need to create a super-set of CONFIG options that
cover any build environment. If some of the CONFIG options turned out
to be unsupported on the build machine, they are automatically disabled
by the nature of Kconfig.
However, it is not feasible to get a full-featured compiler for every
arch.
This issue was discussed here:
https://lkml.org/lkml/2019/12/9/620
Other than distros, savedefconfig is also a problem. Some arch sub-systems
periodically resync defconfig files. If you use a less-capable compiler
for savedefconfig, options that do not meet 'depends on $(cc-option,...)'
will be forcibly disabled. So, 'make defconfig && make savedefconfig'
may silently change the behavior.
This commit adds a set of dummy toolchains that pretend to support any
feature.
Most of compiler features are tested by cc-option, which simply checks
the exit code of $(CC). The dummy tools are shell scripts that always
exit with 0. So, $(cc-option, ...) is evaluated as 'y'.
There are more complicated checks such as:
scripts/gcc-x86_{32,64}-has-stack-protector.sh
scripts/gcc-plugin.sh
scripts/tools-support-relr.sh
scripts/dummy-tools/gcc passes all checks.
From the top directory of the source tree, you can do:
$ make CROSS_COMPILE=scripts/dummy-tools/ oldconfig
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Tested-by: Jeremy Cline <jcline@redhat.com>
2020-04-07 15:53:52 +00:00
|
|
|
exit 0
|
|
|
|
else
|
|
|
|
echo "no input files" >&2
|
|
|
|
exit 1
|
|
|
|
fi
|
|
|
|
fi
|
|
|
|
|
kbuild: check the minimum assembler version in Kconfig
Documentation/process/changes.rst defines the minimum assembler version
(binutils version), but we have never checked it in the build time.
Kbuild never invokes 'as' directly because all assembly files in the
kernel tree are *.S, hence must be preprocessed. I do not expect
raw assembly source files (*.s) would be added to the kernel tree.
Therefore, we always use $(CC) as the assembler driver, and commit
aa824e0c962b ("kbuild: remove AS variable") removed 'AS'. However,
we are still interested in the version of the assembler acting behind.
As usual, the --version option prints the version string.
$ as --version | head -n 1
GNU assembler (GNU Binutils for Ubuntu) 2.35.1
But, we do not have $(AS). So, we can add the -Wa prefix so that
$(CC) passes --version down to the backing assembler.
$ gcc -Wa,--version | head -n 1
gcc: fatal error: no input files
compilation terminated.
OK, we need to input something to satisfy gcc.
$ gcc -Wa,--version -c -x assembler /dev/null -o /dev/null | head -n 1
GNU assembler (GNU Binutils for Ubuntu) 2.35.1
The combination of Clang and GNU assembler works in the same way:
$ clang -no-integrated-as -Wa,--version -c -x assembler /dev/null -o /dev/null | head -n 1
GNU assembler (GNU Binutils for Ubuntu) 2.35.1
Clang with the integrated assembler fails like this:
$ clang -integrated-as -Wa,--version -c -x assembler /dev/null -o /dev/null | head -n 1
clang: error: unsupported argument '--version' to option 'Wa,'
For the last case, checking the error message is fragile. If the
proposal for -Wa,--version support [1] is accepted, this may not be
even an error in the future.
One easy way is to check if -integrated-as is present in the passed
arguments. We did not pass -integrated-as to CLANG_FLAGS before, but
we can make it explicit.
Nathan pointed out -integrated-as is the default for all of the
architectures/targets that the kernel cares about, but it goes
along with "explicit is better than implicit" policy. [2]
With all this in my mind, I implemented scripts/as-version.sh to
check the assembler version in Kconfig time.
$ scripts/as-version.sh gcc
GNU 23501
$ scripts/as-version.sh clang -no-integrated-as
GNU 23501
$ scripts/as-version.sh clang -integrated-as
LLVM 0
[1]: https://github.com/ClangBuiltLinux/linux/issues/1320
[2]: https://lore.kernel.org/linux-kbuild/20210307044253.v3h47ucq6ng25iay@archlinux-ax161/
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
2021-03-15 16:12:56 +00:00
|
|
|
# To set CONFIG_AS_IS_GNU
|
|
|
|
if arg_contain -Wa,--version "$@"; then
|
|
|
|
echo "GNU assembler (scripts/dummy-tools) 2.50"
|
|
|
|
exit 0
|
|
|
|
fi
|
|
|
|
|
kbuild: add dummy toolchains to enable all cc-option etc. in Kconfig
Staring v4.18, Kconfig evaluates compiler capabilities, and hides CONFIG
options your compiler does not support. This works well if you configure
and build the kernel on the same host machine.
It is inconvenient if you prepare the .config that is carried to a
different build environment (typically this happens when you package
the kernel for distros) because using a different compiler potentially
produces different CONFIG options than the real build environment.
So, you probably want to make as many options visible as possible.
In other words, you need to create a super-set of CONFIG options that
cover any build environment. If some of the CONFIG options turned out
to be unsupported on the build machine, they are automatically disabled
by the nature of Kconfig.
However, it is not feasible to get a full-featured compiler for every
arch.
This issue was discussed here:
https://lkml.org/lkml/2019/12/9/620
Other than distros, savedefconfig is also a problem. Some arch sub-systems
periodically resync defconfig files. If you use a less-capable compiler
for savedefconfig, options that do not meet 'depends on $(cc-option,...)'
will be forcibly disabled. So, 'make defconfig && make savedefconfig'
may silently change the behavior.
This commit adds a set of dummy toolchains that pretend to support any
feature.
Most of compiler features are tested by cc-option, which simply checks
the exit code of $(CC). The dummy tools are shell scripts that always
exit with 0. So, $(cc-option, ...) is evaluated as 'y'.
There are more complicated checks such as:
scripts/gcc-x86_{32,64}-has-stack-protector.sh
scripts/gcc-plugin.sh
scripts/tools-support-relr.sh
scripts/dummy-tools/gcc passes all checks.
From the top directory of the source tree, you can do:
$ make CROSS_COMPILE=scripts/dummy-tools/ oldconfig
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Tested-by: Jeremy Cline <jcline@redhat.com>
2020-04-07 15:53:52 +00:00
|
|
|
if arg_contain -S "$@"; then
|
|
|
|
# For scripts/gcc-x86-*-has-stack-protector.sh
|
|
|
|
if arg_contain -fstack-protector "$@"; then
|
2021-05-15 10:11:13 +00:00
|
|
|
if arg_contain -mstack-protector-guard-reg=fs "$@"; then
|
|
|
|
echo "%fs"
|
|
|
|
else
|
|
|
|
echo "%gs"
|
|
|
|
fi
|
kbuild: add dummy toolchains to enable all cc-option etc. in Kconfig
Staring v4.18, Kconfig evaluates compiler capabilities, and hides CONFIG
options your compiler does not support. This works well if you configure
and build the kernel on the same host machine.
It is inconvenient if you prepare the .config that is carried to a
different build environment (typically this happens when you package
the kernel for distros) because using a different compiler potentially
produces different CONFIG options than the real build environment.
So, you probably want to make as many options visible as possible.
In other words, you need to create a super-set of CONFIG options that
cover any build environment. If some of the CONFIG options turned out
to be unsupported on the build machine, they are automatically disabled
by the nature of Kconfig.
However, it is not feasible to get a full-featured compiler for every
arch.
This issue was discussed here:
https://lkml.org/lkml/2019/12/9/620
Other than distros, savedefconfig is also a problem. Some arch sub-systems
periodically resync defconfig files. If you use a less-capable compiler
for savedefconfig, options that do not meet 'depends on $(cc-option,...)'
will be forcibly disabled. So, 'make defconfig && make savedefconfig'
may silently change the behavior.
This commit adds a set of dummy toolchains that pretend to support any
feature.
Most of compiler features are tested by cc-option, which simply checks
the exit code of $(CC). The dummy tools are shell scripts that always
exit with 0. So, $(cc-option, ...) is evaluated as 'y'.
There are more complicated checks such as:
scripts/gcc-x86_{32,64}-has-stack-protector.sh
scripts/gcc-plugin.sh
scripts/tools-support-relr.sh
scripts/dummy-tools/gcc passes all checks.
From the top directory of the source tree, you can do:
$ make CROSS_COMPILE=scripts/dummy-tools/ oldconfig
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Tested-by: Jeremy Cline <jcline@redhat.com>
2020-04-07 15:53:52 +00:00
|
|
|
exit 0
|
|
|
|
fi
|
2021-03-08 06:28:20 +00:00
|
|
|
|
|
|
|
# For arch/powerpc/tools/gcc-check-mprofile-kernel.sh
|
2023-08-29 10:51:06 +00:00
|
|
|
if arg_contain -m64 "$@" && arg_contain -mprofile-kernel "$@"; then
|
2021-03-08 06:28:20 +00:00
|
|
|
if ! test -t 0 && ! grep -q notrace; then
|
|
|
|
echo "_mcount"
|
|
|
|
fi
|
|
|
|
exit 0
|
|
|
|
fi
|
2023-10-30 11:34:16 +00:00
|
|
|
|
|
|
|
# For arch/powerpc/tools/gcc-check-fpatchable-function-entry.sh
|
|
|
|
if arg_contain -m64 "$@" && arg_contain -fpatchable-function-entry=2 "$@"; then
|
|
|
|
echo "func:"
|
|
|
|
echo ".section __patchable_function_entries"
|
|
|
|
echo ".localentry"
|
|
|
|
echo " nop"
|
|
|
|
echo " nop"
|
|
|
|
exit 0
|
|
|
|
fi
|
kbuild: add dummy toolchains to enable all cc-option etc. in Kconfig
Staring v4.18, Kconfig evaluates compiler capabilities, and hides CONFIG
options your compiler does not support. This works well if you configure
and build the kernel on the same host machine.
It is inconvenient if you prepare the .config that is carried to a
different build environment (typically this happens when you package
the kernel for distros) because using a different compiler potentially
produces different CONFIG options than the real build environment.
So, you probably want to make as many options visible as possible.
In other words, you need to create a super-set of CONFIG options that
cover any build environment. If some of the CONFIG options turned out
to be unsupported on the build machine, they are automatically disabled
by the nature of Kconfig.
However, it is not feasible to get a full-featured compiler for every
arch.
This issue was discussed here:
https://lkml.org/lkml/2019/12/9/620
Other than distros, savedefconfig is also a problem. Some arch sub-systems
periodically resync defconfig files. If you use a less-capable compiler
for savedefconfig, options that do not meet 'depends on $(cc-option,...)'
will be forcibly disabled. So, 'make defconfig && make savedefconfig'
may silently change the behavior.
This commit adds a set of dummy toolchains that pretend to support any
feature.
Most of compiler features are tested by cc-option, which simply checks
the exit code of $(CC). The dummy tools are shell scripts that always
exit with 0. So, $(cc-option, ...) is evaluated as 'y'.
There are more complicated checks such as:
scripts/gcc-x86_{32,64}-has-stack-protector.sh
scripts/gcc-plugin.sh
scripts/tools-support-relr.sh
scripts/dummy-tools/gcc passes all checks.
From the top directory of the source tree, you can do:
$ make CROSS_COMPILE=scripts/dummy-tools/ oldconfig
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Tested-by: Jeremy Cline <jcline@redhat.com>
2020-04-07 15:53:52 +00:00
|
|
|
fi
|
|
|
|
|
2021-01-23 09:16:30 +00:00
|
|
|
# To set GCC_PLUGINS
|
kbuild: add dummy toolchains to enable all cc-option etc. in Kconfig
Staring v4.18, Kconfig evaluates compiler capabilities, and hides CONFIG
options your compiler does not support. This works well if you configure
and build the kernel on the same host machine.
It is inconvenient if you prepare the .config that is carried to a
different build environment (typically this happens when you package
the kernel for distros) because using a different compiler potentially
produces different CONFIG options than the real build environment.
So, you probably want to make as many options visible as possible.
In other words, you need to create a super-set of CONFIG options that
cover any build environment. If some of the CONFIG options turned out
to be unsupported on the build machine, they are automatically disabled
by the nature of Kconfig.
However, it is not feasible to get a full-featured compiler for every
arch.
This issue was discussed here:
https://lkml.org/lkml/2019/12/9/620
Other than distros, savedefconfig is also a problem. Some arch sub-systems
periodically resync defconfig files. If you use a less-capable compiler
for savedefconfig, options that do not meet 'depends on $(cc-option,...)'
will be forcibly disabled. So, 'make defconfig && make savedefconfig'
may silently change the behavior.
This commit adds a set of dummy toolchains that pretend to support any
feature.
Most of compiler features are tested by cc-option, which simply checks
the exit code of $(CC). The dummy tools are shell scripts that always
exit with 0. So, $(cc-option, ...) is evaluated as 'y'.
There are more complicated checks such as:
scripts/gcc-x86_{32,64}-has-stack-protector.sh
scripts/gcc-plugin.sh
scripts/tools-support-relr.sh
scripts/dummy-tools/gcc passes all checks.
From the top directory of the source tree, you can do:
$ make CROSS_COMPILE=scripts/dummy-tools/ oldconfig
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Tested-by: Jeremy Cline <jcline@redhat.com>
2020-04-07 15:53:52 +00:00
|
|
|
if arg_contain -print-file-name=plugin "$@"; then
|
2022-07-11 12:09:23 +00:00
|
|
|
# Use $0 to find the in-tree dummy directory
|
|
|
|
echo "$(dirname "$(readlink -f "$0")")/dummy-plugin-dir"
|
kbuild: add dummy toolchains to enable all cc-option etc. in Kconfig
Staring v4.18, Kconfig evaluates compiler capabilities, and hides CONFIG
options your compiler does not support. This works well if you configure
and build the kernel on the same host machine.
It is inconvenient if you prepare the .config that is carried to a
different build environment (typically this happens when you package
the kernel for distros) because using a different compiler potentially
produces different CONFIG options than the real build environment.
So, you probably want to make as many options visible as possible.
In other words, you need to create a super-set of CONFIG options that
cover any build environment. If some of the CONFIG options turned out
to be unsupported on the build machine, they are automatically disabled
by the nature of Kconfig.
However, it is not feasible to get a full-featured compiler for every
arch.
This issue was discussed here:
https://lkml.org/lkml/2019/12/9/620
Other than distros, savedefconfig is also a problem. Some arch sub-systems
periodically resync defconfig files. If you use a less-capable compiler
for savedefconfig, options that do not meet 'depends on $(cc-option,...)'
will be forcibly disabled. So, 'make defconfig && make savedefconfig'
may silently change the behavior.
This commit adds a set of dummy toolchains that pretend to support any
feature.
Most of compiler features are tested by cc-option, which simply checks
the exit code of $(CC). The dummy tools are shell scripts that always
exit with 0. So, $(cc-option, ...) is evaluated as 'y'.
There are more complicated checks such as:
scripts/gcc-x86_{32,64}-has-stack-protector.sh
scripts/gcc-plugin.sh
scripts/tools-support-relr.sh
scripts/dummy-tools/gcc passes all checks.
From the top directory of the source tree, you can do:
$ make CROSS_COMPILE=scripts/dummy-tools/ oldconfig
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Tested-by: Jeremy Cline <jcline@redhat.com>
2020-04-07 15:53:52 +00:00
|
|
|
exit 0
|
|
|
|
fi
|
2021-03-03 10:43:14 +00:00
|
|
|
|
|
|
|
# inverted return value
|
|
|
|
if arg_contain -D__SIZEOF_INT128__=0 "$@"; then
|
|
|
|
exit 1
|
|
|
|
fi
|