Commit Graph

15 Commits

Author SHA1 Message Date
Masahiro Yamada
4d0831e8a0 kconfig: unify cc-option and as-option
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 7b16994437 ("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 $?
  0

There 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
  <stdin>:1: error: cannot open /dev/null.gcno

So, 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 <masahiroy@kernel.org>
Acked-by: Will Deacon <will@kernel.org>
2020-06-17 10:38:42 +09:00
Masahiro Yamada
77342a02ff gcc-plugins: drop support for GCC <= 4.7
Nobody was opposed to raising minimum GCC version to 4.8 [1]
So, we will drop GCC <= 4.7 support sooner or later.

We always use C++ compiler for building plugins for GCC >= 4.8.

This commit drops the plugin support for GCC <= 4.7 a bit earlier,
which allows us to dump lots of code.

[1] https://lkml.org/lkml/2020/1/23/545

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Kees Cook <keescook@chromium.org>
2020-04-09 00:13:45 +09:00
Linus Torvalds
3cd86a58f7 arm64 updates for 5.7:
- 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.
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEE5RElWfyWxS+3PLO2a9axLQDIXvEFAl6DVyIACgkQa9axLQDI
 XvHkqRAAiZA2EYKiQL4M1DJ1cNTADjT7xKX9+UtYBXj7GMVhgVWdunpHVE6qtfgk
 cT6avmKrS/6PDqizJgr+Z1yX8x3Kvs57G4BvmIUKIw97mkdewvFQ9JKv6VA1vb86
 7Qrl1WzqsGg5Kj9uUfI4h+ZoT1H4C/9PQeFxJwgZRtF9DxRh8O7VeZI+JCu8Aub2
 lIkjI8rh+EpTsGT9h/PMGWUcawnKQloZ1/F+GfMAuYBvIv2RNN2xVreJtTmm4NyJ
 VcpL0KCNyAI2lGdaJg5nBLRDyGuXDm5i+PLsCSXMquI4fie00txXeD8sjbeuO0ks
 YTJ0EhmUUhbSE17go+SxYiEFE0v09i+lD5ud+B4Vmojp0KTczTta9VSgURlbb2/9
 n9biq5G3PPDNIrZqiTT2Tf4AMz1350nkbzL2gzKecM5aIzR/u3y5yII5CgfZtFnj
 7bGbyFpFpcqI7UaISPsNCxmknbTt/7ff0WM3+7SbecxI3AD2mnxsOdN9JTLyhDp+
 owjyiaWxl5zMWF9DhplLG/9BKpNWSxh3skazdOdELd8GTq2MbJlXrVG2XgXTAOh3
 y1s6RQrfw8zXh8TSqdmmzauComXIRWTum/sbVB3U8Z3AUsIeq/NTSbN5X9JyIbOP
 HOabhlVhhkI6omN1grqPX4jwUiZLZoNfn7Ez4q71549KVK/uBtA=
 =LJVX
 -----END PGP SIGNATURE-----

Merge tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux

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
  ...
2020-03-31 10:05:01 -07:00
Vincenzo Frascino
c2d920bf1f kconfig: Add support for 'as-option'
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 <amit.kachhap@arm.com>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Acked-by: Masahiro Yamada <masahiroy@kernel.org>
Cc: linux-kbuild@vger.kernel.org
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2020-03-18 09:50:21 +00:00
Masahiro Yamada
8cc4fd7350 kconfig: introduce m32-flag and m64-flag
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 e8de12fb7c ("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 <masahiroy@kernel.org>
Tested-by: George Spelvin <lkml@sdf.org>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
2020-03-12 07:42:27 +09:00
Linus Torvalds
368d060bb4 Kbuild updates for v5.6
- 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
 -----BEGIN PGP SIGNATURE-----
 
 iQJJBAABCgAzFiEEbmPs18K1szRHjPqEPYsBB53g2wYFAl409uwVHG1hc2FoaXJv
 eUBrZXJuZWwub3JnAAoJED2LAQed4NsG6vAP/jky7LSuv6lpIcYhxOmzFfs7qTlA
 llZDmzTPi26/doV1P9LYMw6Pd4HV6Zeo/aFLolirCsp0kFBW/5b2C68OsXfotJOD
 0YxPeFMIsumsmAVdQ7lGQerS19BDcMrFJiKoLUuULH3bH0mjL/YVlFVg0Dmq77j1
 PDsyTihROajVmJBf8UMK65nUdCSLZihBsKyvj7SxYnlHAS1EaAT+RiwE7qAHoYW9
 C3TYwOa1e8u/0FmosKxSChl9Pq5ti/gcK4dVLs7bm4LmJEsqmLeR8BDM8xlaT/FE
 lFl7iPLO2cvhy76NsK8YBnTcRD445gBn+M3XFKZ3sDTVj7TkdaIWtVurf5IYo+BN
 bTJHac1E9nbpv6L7QIXhxLCGozEi0+pv/8pyhIrAv8XxmZXp7HJbon+siEg8Glez
 rbwM44kNPQk8xovVcoixh4+qRH9l49+zzT0h0kY1PWfJ6hp0D1xmG/v3kai8dErt
 X4w7xi5gOssYwZ5M0LuOQprDeL5DV/Caz5R1+maqVb2yhn2EBsJ6wC24/vawxhFj
 Kjx1g/NZIW4lnBrF1Ay4geF+f+0jd1bcTBqtNmC09uSTIBvEysZ3HNBf4Z9PFTGW
 jdQ7Qpowgy9SOLqZuE+OAuojq7xhfm1fkm/MBUFUYh/HKOXoiLAnVK1+x0BM0yJB
 ZhMwvmj9fKoqVpzx
 =i/xZ
 -----END PGP SIGNATURE-----

Merge tag 'kbuild-v5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild

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
  ...
2020-02-01 10:01:52 -08:00
Masahiro Yamada
3bed1b7b9d kbuild: use -S instead of -E for precise cc-option test in Kconfig
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 <masahiroy@kernel.org>
2020-01-22 11:04:28 +09:00
Catalin Marinas
42d519e3d0 kbuild: Add support for 'as-instr' to be used in Kconfig files
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 <masahiroy@kernel.org>
Reviewed-by: Vladimir Murzin <vladimir.murzin@arm.com>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
2020-01-15 12:50:36 +00:00
Thomas Gleixner
75959d44f9 kbuild: Fail if gold linker is detected
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 <tglx@linutronix.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/CAMe9rOqMqkQ0LNpm25yE_Yt0FKp05WmHOrwc0aRDb53miFKM+w@mail.gmail.com
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-08-14 01:10:42 +09:00
Stephen Boyd
e8de12fb7c kbuild: Check for unknown options with cc-option usage in Kconfig and clang
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
589834b3a0 ("kbuild: Add -Werror=unknown-warning-option to
CLANG_FLAGS") was applied on top of commit b303c6df80 ("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 589834b3a0 ("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 <peter.smith@linaro.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-08-01 00:12:07 +09:00
Thomas Gleixner
ec8f24b7fa treewide: Add SPDX license identifier - Makefile/Kconfig
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 <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21 10:50:46 +02:00
Masahiro Yamada
902a6898bf kbuild: terminate Kconfig when $(CC) or $(LD) is missing
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 <yamada.masahiro@socionext.com>
2019-05-18 11:49:55 +09:00
Masahiro Yamada
fa7295ab69 kbuild: clean up scripts/gcc-version.sh
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 <yamada.masahiro@socionext.com>
2019-03-04 22:35:04 +09:00
Masahiro Yamada
59f53855ba gcc-plugins: test plugin support in Kconfig and clean up Makefile
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 <yamada.masahiro@socionext.com>
Acked-by: Kees Cook <keescook@chromium.org>
2018-06-11 09:16:22 +09:00
Masahiro Yamada
e1cfdc0e72 kconfig: add basic helper macros to scripts/Kconfig.include
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 <yamada.masahiro@socionext.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
2018-05-29 03:31:19 +09:00