17 Jun, 2020
1 commit
-
cc-option and as-option are almost the same; both pass the flag to
$(CC). The main difference is the cc-option stops before the assemble
stage (-S option) whereas as-option stops after (-c option).I chose -S because it is slightly faster, but $(cc-option,-gz=zlib)
returns a wrong result (https://lkml.org/lkml/2020/6/9/1529).
It has been fixed by commit 7b16994437c7 ("Makefile: Improve compressed
debug info support detection"), but the assembler should always be
invoked for more reliable compiler option tests.However, you cannot simply replace -S with -c because the following
code in lib/Kconfig.debug would break:depends on $(cc-option,-gsplit-dwarf)
The combination of -c and -gsplit-dwarf does not accept /dev/null as
output.$ cat /dev/null | gcc -gsplit-dwarf -S -x c - -o /dev/null
$ echo $?
0$ cat /dev/null | gcc -gsplit-dwarf -c -x c - -o /dev/null
objcopy: Warning: '/dev/null' is not an ordinary file
$ echo $?
1$ cat /dev/null | gcc -gsplit-dwarf -c -x c - -o tmp.o
$ echo $?
0There is another flag that creates an separate file based on the
object file path:$ cat /dev/null | gcc -ftest-coverage -c -x c - -o /dev/null
:1: error: cannot open /dev/null.gcnoSo, we cannot use /dev/null to sink the output.
Align the cc-option implementation with scripts/Kbuild.include.
With -c option used in cc-option, as-option is unneeded.
Signed-off-by: Masahiro Yamada
Acked-by: Will Deacon
08 Apr, 2020
1 commit
-
Nobody was opposed to raising minimum GCC version to 4.8 [1]
So, we will drop GCC = 4.8.This commit drops the plugin support for GCC
Acked-by: Kees Cook
01 Apr, 2020
1 commit
-
Pull arm64 updates from Catalin Marinas:
"The bulk is in-kernel pointer authentication, activity monitors and
lots of asm symbol annotations. I also queued the sys_mremap() patch
commenting the asymmetry in the address untagging.Summary:
- In-kernel Pointer Authentication support (previously only offered
to user space).- ARM Activity Monitors (AMU) extension support allowing better CPU
utilisation numbers for the scheduler (frequency invariance).- Memory hot-remove support for arm64.
- Lots of asm annotations (SYM_*) in preparation for the in-kernel
Branch Target Identification (BTI) support.- arm64 perf updates: ARMv8.5-PMU 64-bit counters, refactoring the
PMU init callbacks, support for new DT compatibles.- IPv6 header checksum optimisation.
- Fixes: SDEI (software delegated exception interface) double-lock on
hibernate with shared events.- Minor clean-ups and refactoring: cpu_ops accessor,
cpu_do_switch_mm() converted to C, cpufeature finalisation helper.- sys_mremap() comment explaining the asymmetric address untagging
behaviour"* tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (81 commits)
mm/mremap: Add comment explaining the untagging behaviour of mremap()
arm64: head: Convert install_el2_stub to SYM_INNER_LABEL
arm64: Introduce get_cpu_ops() helper function
arm64: Rename cpu_read_ops() to init_cpu_ops()
arm64: Declare ACPI parking protocol CPU operation if needed
arm64: move kimage_vaddr to .rodata
arm64: use mov_q instead of literal ldr
arm64: Kconfig: verify binutils support for ARM64_PTR_AUTH
lkdtm: arm64: test kernel pointer authentication
arm64: compile the kernel with ptrauth return address signing
kconfig: Add support for 'as-option'
arm64: suspend: restore the kernel ptrauth keys
arm64: __show_regs: strip PAC from lr in printk
arm64: unwind: strip PAC from kernel addresses
arm64: mask PAC bits of __builtin_return_address
arm64: initialize ptrauth keys for kernel booting task
arm64: initialize and switch ptrauth kernel keys
arm64: enable ptrauth earlier
arm64: cpufeature: handle conflicts based on capability
arm64: cpufeature: Move cpu capability helpers inside C file
...
18 Mar, 2020
1 commit
-
Currently kconfig does not have a feature that allows to detect if the
used assembler supports a specific compilation option.Introduce 'as-option' to serve this purpose in the context of Kconfig:
config X
def_bool $(as-option,...)Signed-off-by: Amit Daniel Kachhap
Signed-off-by: Vincenzo Frascino
Acked-by: Masahiro Yamada
Cc: linux-kbuild@vger.kernel.org
Cc: Masahiro Yamada
Signed-off-by: Catalin Marinas
12 Mar, 2020
1 commit
-
When a compiler supports multiple architectures, some compiler features
can be dependent on the target architecture.This is typical for Clang, which supports multiple LLVM backends.
Even for GCC, we need to take care of biarch compiler cases.It is not a problem when we evaluate cc-option in Makefiles because
cc-option is tested against the flag in question + $(KBUILD_CFLAGS).The cc-option in Kconfig, on the other hand, does not accumulate
tested flags. Due to this simplification, it could potentially test
cc-option against a different target.At first, Kconfig always evaluated cc-option against the host
architecture.Since commit e8de12fb7cde ("kbuild: Check for unknown options with
cc-option usage in Kconfig and clang"), in case of cross-compiling
with Clang, the target triple is correctly passed to Kconfig.The case with biarch GCC (and native build with Clang) is still not
handled properly. We need to pass some flags to specify the target
machine bit.Due to the design, all the macros in Kconfig are expanded in the
parse stage, where we do not know the target bit size yet.For example, arch/x86/Kconfig allows a user to toggle CONFIG_64BIT.
If a compiler flag -foo depends on the machine bit, it must be tested
twice, one with -m32 and the other with -m64.However, -m32/-m64 are not always recognized. So, this commits adds
m64-flag and m32-flag macros. They expand to -m32, -m64, respectively
if supported. Or, they expand to an empty string if unsupported.The typical usage is like this:
config FOO
bool
default $(cc-option,$(m64-flag) -foo) if 64BIT
default $(cc-option,$(m32-flag) -foo)This is clumsy, but there is no elegant way to handle this in the
current static macro expansion.There was discussion for static functions vs dynamic functions.
The consensus was to go as far as possible with the static functions.
(https://lkml.org/lkml/2018/3/2/22)Signed-off-by: Masahiro Yamada
Tested-by: George Spelvin
Reviewed-by: Nathan Chancellor
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
...
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 $?
1Signed-off-by: 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
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
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
21 May, 2019
1 commit
-
Add SPDX license identifiers to all Make/Kconfig files which:
- Have no license information of any form
These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:GPL-2.0-only
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
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 2Signed-off-by: Masahiro Yamada
04 Mar, 2019
1 commit
-
Now that the Kconfig is the only user of this script, we can drop
unneeded code.Remove the -p option, and stop prepending the output with zero,
so that Kconfig can directly use the output from this script.Signed-off-by: Masahiro Yamada
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
29 May, 2018
1 commit
-
Kconfig got text processing tools like we see in Make. Add Kconfig
helper macros to scripts/Kconfig.include like we collect Makefile
macros in scripts/Kbuild.include.Signed-off-by: Masahiro Yamada
Reviewed-by: Kees Cook
Reviewed-by: Ulf Magnusson