conf_askvalue() is only called for oldconfig, syncconfig, and
oldaskconfig. If it is called for other cases, it is a bug.
So, the code after the switch statement is unreachable.
Remove the dead code, and clean up the switch statement.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Unify the outer two if-conditionals into one. This decreases the
indent level by one.
Also, change the if-else blocks:
if (input_mode == listnewconfig) {
...
} else if (input_mode == helpnewconfig) {
...
} else {
...
}
into the switch statement.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Use the saved returned value of sym_get_string_value() instead of
calling it twice.
Signed-off-by: Mickaël Salaün <mic@linux.microsoft.com>
Link: https://lore.kernel.org/r/20210215181511.2840674-2-mic@digikod.net
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Unify the two scripts/ld-version.sh and scripts/lld-version.sh, and
check the minimum linker version like scripts/cc-version.sh did.
I tested this script for some corner cases reported in the past:
- GNU ld version 2.25-15.fc23
as reported by commit 8083013fc3 ("ld-version: Fix it on Fedora")
- GNU ld (GNU Binutils) 2.20.1.20100303
as reported by commit 0d61ed17dd ("ld-version: Drop the 4th and
5th version components")
This script show an error message if the linker is too old:
$ make LD=ld.lld-9
SYNC include/config/auto.conf
***
*** Linker is too old.
*** Your LLD version: 9.0.1
*** Minimum LLD version: 10.0.1
***
scripts/Kconfig.include:50: Sorry, this linker is not supported.
make[2]: *** [scripts/kconfig/Makefile:71: syncconfig] Error 1
make[1]: *** [Makefile:600: syncconfig] Error 2
make: *** [Makefile:708: include/config/auto.conf] Error 2
I also moved the check for gold to this script, so gold is still rejected:
$ make LD=gold
SYNC include/config/auto.conf
gold linker is not supported as it is not capable of linking the kernel proper.
scripts/Kconfig.include:50: Sorry, this linker is not supported.
make[2]: *** [scripts/kconfig/Makefile:71: syncconfig] Error 1
make[1]: *** [Makefile:600: syncconfig] Error 2
make: *** [Makefile:708: include/config/auto.conf] Error 2
Thanks to David Laight for suggesting shell script improvements.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
There is no direct user of ld-version; you can use CONFIG_LD_VERSION
if needed.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Most of architectures generate syscall headers at the compile time
in a similar way.
As of v5.11-rc1, 12 architectures duplicate similar shell scripts:
$ find arch -name syscallhdr.sh | sort
arch/alpha/kernel/syscalls/syscallhdr.sh
arch/arm/tools/syscallhdr.sh
arch/ia64/kernel/syscalls/syscallhdr.sh
arch/m68k/kernel/syscalls/syscallhdr.sh
arch/microblaze/kernel/syscalls/syscallhdr.sh
arch/mips/kernel/syscalls/syscallhdr.sh
arch/parisc/kernel/syscalls/syscallhdr.sh
arch/powerpc/kernel/syscalls/syscallhdr.sh
arch/sh/kernel/syscalls/syscallhdr.sh
arch/sparc/kernel/syscalls/syscallhdr.sh
arch/x86/entry/syscalls/syscallhdr.sh
arch/xtensa/kernel/syscalls/syscallhdr.sh
My goal is to unify them into scripts/syscallhdr.sh.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Most of architectures generate syscall headers at the compile time
in a similar way.
The syscall table has the same format for all architectures. Each line
has up to 5 fields; syscall number, ABI, syscall name, native entry
point, and compat entry point. The syscall table is processed by
syscalltbl.sh script into header files.
Despite the same pattern, scripts are maintained per architecture,
which results in code duplication and bad maintainability.
As of v5.11-rc1, 12 architectures duplicate similar shell scripts:
$ find arch -name syscalltbl.sh | sort
arch/alpha/kernel/syscalls/syscalltbl.sh
arch/arm/tools/syscalltbl.sh
arch/ia64/kernel/syscalls/syscalltbl.sh
arch/m68k/kernel/syscalls/syscalltbl.sh
arch/microblaze/kernel/syscalls/syscalltbl.sh
arch/mips/kernel/syscalls/syscalltbl.sh
arch/parisc/kernel/syscalls/syscalltbl.sh
arch/powerpc/kernel/syscalls/syscalltbl.sh
arch/sh/kernel/syscalls/syscalltbl.sh
arch/sparc/kernel/syscalls/syscalltbl.sh
arch/x86/entry/syscalls/syscalltbl.sh
arch/xtensa/kernel/syscalls/syscalltbl.sh
My goal is to unify them into scripts/syscalltbl.sh.
__SYSCALL_WITH_COMPAT should be defined as follows:
32-bit kernel:
#define __SYSCALL_WITH_COMPAT(nr, native, compat) __SYSCALL(nr, native)
64-bit kernel:
#define __SYSCALL_WITH_COMPAT(nr, native, compat) __SYSCALL(nr, compat)
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
If directories are passed to gen_compile_commands.py, os.walk() traverses
all the subdirectories to search for .cmd files, but we know some of them
are not worth traversing.
Use the 'topdown' parameter of os.walk to prune them.
Documentation about the 'topdown' option of os.walk:
When topdown is True, the caller can modify the dirnames list
in-place (perhaps using del or slice assignment), and walk() will
only recurse into the subdirectories whose names remain in dirnames;
this can be used to prune the search, impose a specific order of
visiting, or even to inform walk() about directories the caller
creates or renames before it resumes walk() again. Modifying
dirnames when topdown is False has no effect on the behavior of
the walk, because in bottom-up mode the directories in dirnames
are generated before dirpath itself is generated.
This commit prunes four directories, .git, Documentation, include, and
tools.
The first three do not contain any C files, so skipping them makes this
script work slightly faster. My main motivation is the last one, tools/
directory.
Commit 6ca4c6d259 ("gen_compile_commands: do not support .cmd files
under tools/ directory") stopped supporting the tools/ directory.
The current code no longer picks up .cmd files from the tools/
directory.
If you run:
./scripts/clang-tools/gen_compile_commands.py --log_level=INFO
then, you will see several "File ... not found" log messages.
This is expected, and I do not want to support the tools/ directory.
However, without an explicit comment "do not support tools/", somebody
might try to get it back. Clarify this.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Nathan Chancellor <nathan@kernel.org>
DWARF v5 is the latest standard of the DWARF debug info format. GCC 11
will change the implicit default DWARF version, if left unspecified, to
DWARF v5.
Allow users of Clang and older versions of GCC that have not changed the
implicit default DWARF version to DWARF v5 to opt in. This can help
testing consumers of DWARF debug info in preparation of v5 becoming more
widespread, as well as result in significant binary size savings of the
pre-stripped vmlinux image.
DWARF5 wins significantly in terms of size when mixed with compression
(CONFIG_DEBUG_INFO_COMPRESSED).
363M vmlinux.clang12.dwarf5.compressed
434M vmlinux.clang12.dwarf4.compressed
439M vmlinux.clang12.dwarf2.compressed
457M vmlinux.clang12.dwarf5
536M vmlinux.clang12.dwarf4
548M vmlinux.clang12.dwarf2
515M vmlinux.gcc10.2.dwarf5.compressed
599M vmlinux.gcc10.2.dwarf4.compressed
624M vmlinux.gcc10.2.dwarf2.compressed
630M vmlinux.gcc10.2.dwarf5
765M vmlinux.gcc10.2.dwarf4
809M vmlinux.gcc10.2.dwarf2
Though the quality of debug info is harder to quantify; size is not a
proxy for quality.
Jakub notes:
One thing is GCC DWARF-5 support, that is whether the compiler will
support -gdwarf-5 flag, and that support should be there from GCC 7
onwards.
All [GCC] 5.1 - 6.x did was start accepting -gdwarf-5 as experimental
option that enabled some small DWARF subset (initially only a few
DW_LANG_* codes newly added to DWARF5 drafts). Only GCC 7 (released
after DWARF 5 has been finalized) started emitting DWARF5 section
headers and got most of the DWARF5 changes in...
Another separate thing is whether the assembler does support
the -gdwarf-5 option (i.e. if you can compile assembler files
with -Wa,-gdwarf-5) ... That option is about whether the assembler
will emit DWARF5 or DWARF2 .debug_line. It is fine to compile C sources
with -gdwarf-5 and use DWARF2 .debug_line for assembler files if as
doesn't support it.
Version check GCC so that we don't need to worry about the difference in
command line args between GNU readelf and llvm-readelf/llvm-dwarfdump to
validate the DWARF Version in the assembler feature detection script.
Most issues with clang produced assembler were fixed in binutils 2.35.1,
but 2.35.2 fixed issues related to requiring the flag -Wa,-gdwarf-5
explicitly. The added shell script test checks for the latter, and is
only required when using clang without its integrated assembler, though
we use for clang regardless as we do not yet have a way to query the
assembler from Kconfig.
Disabled for now if CONFIG_DEBUG_INFO_BTF is set; pahole doesn't yet
recognize the new additions to the DWARF debug info.
This only modifies the DWARF version emitted by the compiler, not the
assembler.
The DWARF version of a binary can be validated with:
$ llvm-dwarfdump <object file> | head -n 4 | grep version
or
$ readelf --debug-dump=info <object file> 2>/dev/null | grep Version
Parts of the tree don't reuse DEBUG_CFLAGS as they should; such cleanup
is left as a follow up.
Link: http://www.dwarfstd.org/doc/DWARF5.pdf
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1922707
Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
Suggested-by: Arvind Sankar <nivedita@alum.mit.edu>
Suggested-by: Caroline Tice <cmtice@google.com>
Suggested-by: Fangrui Song <maskray@google.com>
Suggested-by: Jakub Jelinek <jakub@redhat.com>
Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
Suggested-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # LLVM/Clang v12.0.0-rc1 x86-64
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
As commit d0e628cd81 ("kbuild: doc: clarify the difference between
extra-y and always-y") explained, extra-y should be used for listing
the prerequisites of vmlinux.
These targets are not related to vmlinux. always-y is a better fix.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
This switch statement does not list out all the cases. Since the
'default' covers all the rest, the 'DOTS' case is unneeded.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
No one sets lexstate to ST_TABLE_*. It is is very old code, and I do
not know what was the plan at that time. Let's remove the dead code.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Paul Gortmaker reported a regression in the GCC version check. [1]
If you use GCC 4.8, the build breaks before showing the error message
"error Sorry, your version of GCC is too old - please use 4.9 or newer."
I do not want to apply his fix-up since it implies we would not be able
to remove any cc-option test. Anyway, I admit checking the GCC version
in <linux/compiler-gcc.h> is too late.
Almost at the same time, Linus also suggested to move the compiler
version error to Kconfig time. [2]
I unified the two similar scripts, gcc-version.sh and clang-version.sh
into cc-version.sh. The old scripts invoked the compiler multiple times
(3 times for gcc-version.sh, 4 times for clang-version.sh). I refactored
the code so the new one invokes the compiler just once, and also tried
my best to use shell-builtin commands where possible.
The new script runs faster.
$ time ./scripts/clang-version.sh clang
120000
real 0m0.029s
user 0m0.012s
sys 0m0.021s
$ time ./scripts/cc-version.sh clang
Clang 120000
real 0m0.009s
user 0m0.006s
sys 0m0.004s
cc-version.sh also shows an error message if the compiler is too old:
$ make defconfig CC=clang-9
*** Default configuration is based on 'x86_64_defconfig'
***
*** Compiler is too old.
*** Your Clang version: 9.0.1
*** Minimum Clang version: 10.0.1
***
scripts/Kconfig.include:46: Sorry, this compiler is not supported.
make[1]: *** [scripts/kconfig/Makefile:81: defconfig] Error 1
make: *** [Makefile:602: defconfig] Error 2
The new script takes care of ICC because we have <linux/compiler-intel.h>
although I am not sure if building the kernel with ICC is well-supported.
[1]: https://lore.kernel.org/r/20210110190807.134996-1-paul.gortmaker@windriver.com
[2]: https://lore.kernel.org/r/CAHk-=wh-+TMHPTFo1qs-MYyK7tZh-OQovA=pP3=e06aCVp6_kA@mail.gmail.com
Fixes: 87de84c914 ("kbuild: remove cc-option test of -Werror=date-time")
Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
Tested-by: Miguel Ojeda <ojeda@kernel.org>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Commit ccbef1674a ("Kbuild, lto: add ld-version and ld-ifversion
macros") introduced scripts/ld-version.sh for GCC LTO.
At that time, this script handled 5 version fields because GCC LTO
needed the downstream binutils. (https://lkml.org/lkml/2014/4/8/272)
The code snippet from the submitted patch was as follows:
# We need HJ Lu's Linux binutils because mainline binutils does not
# support mixing assembler and LTO code in the same ld -r object.
# XXX check if the gcc plugin ld is the expected one too
# XXX some Fedora binutils should also support it. How to check for that?
ifeq ($(call ld-ifversion,-ge,22710001,y),y)
...
However, GCC LTO was not merged into the mainline after all.
(https://lkml.org/lkml/2014/4/8/272)
So, the 4th and 5th fields were never used, and finally removed by
commit 0d61ed17dd ("ld-version: Drop the 4th and 5th version
components").
Since then, the last 4-digits returned by this script is always zeros.
Remove the meaningless last 4-digits. This makes the version format
consistent with GCC_VERSION, CLANG_VERSION, LLD_VERSION.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Will Deacon <will@kernel.org>
Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
ARM randconfig builds with lld sometimes show a build failure
from kallsyms:
Inconsistent kallsyms data
Try make KALLSYMS_EXTRA_PASS=1 as a workaround
The problem is the veneers/thunks getting added by the linker extend
the symbol table, which in turn leads to more veneers being needed,
so it may take a few extra iterations to converge.
This bug has been fixed multiple times before, but comes back every time
a new symbol name is used. lld uses a different set of identifiers from
ld.bfd, so the additional ones need to be added as well.
I looked through the sources and found that arm64 and mips define similar
prefixes, so I'm adding those as well, aside from the ones I observed. I'm
not sure about powerpc64, which seems to already be handled through a
section match, but if it comes back, the "__long_branch_" and "__plt_"
prefixes would have to get added as well.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
For the same reason as commit 51839e29cb ("scripts: switch explicitly
to Python 3"), switch some more scripts, which I tested and confirmed
working on Python 3.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Nathan Chancellor <nathan@kernel.org>
Python retired in 2020, and some distributions do not provide the
'python' command any more.
As in commit 51839e29cb ("scripts: switch explicitly to Python 3"),
we need to use more specific 'python3' to invoke scripts even if they
are written in a way compatible with both Python 2 and 3.
This commit removes the variable 'PYTHON', and switches the existing
users to 'PYTHON3'.
BTW, PEP 394 (https://www.python.org/dev/peps/pep-0394/) is a helpful
material.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
This reverts commit 327953e9af.
You cannot use 'boolean' since commit b92d804a51 ("kconfig: drop
'boolean' keyword").
This check is no longer needed.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Joe Perches <joe@perches.com>
Otherwise build fails if the headers are not in the default location. While at
it also ask pkg-config for the libs, with fallback to the existing value.
Signed-off-by: Rolf Eike Beer <eb@emlix.com>
Cc: stable@vger.kernel.org # 5.6.x
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Commit c0f975af17 ("kconfig: Support building mconf with vendor
sysroot ncurses") introduces a bug when HOSTCC contains parameters:
the whole command line is treated as the program name (with spaces
in it). Therefore, we have to remove the quotes.
Fixes: c0f975af17 ("kconfig: Support building mconf with vendor sysroot ncurses")
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
With commit 1e860048c5 ("gcc-plugins: simplify GCC plugin-dev
capability test") applied, this hunk can be way simplified because
now scripts/gcc-plugins/Kconfig only checks plugin-version.h
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Some distributions are about to switch to Python 3 support only.
This means that /usr/bin/python, which is Python 2, is not available
anymore. Hence, switch scripts to use Python 3 explicitly.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
- Search for <ncurses.h> in the default header path of HOSTCC
- Tweak the option order to be kind to old BSD awk
- Remove 'kvmconfig' and 'xenconfig' shorthands
- Fix documentation
-----BEGIN PGP SIGNATURE-----
iQJJBAABCgAzFiEEbmPs18K1szRHjPqEPYsBB53g2wYFAl/7YsgVHG1hc2FoaXJv
eUBrZXJuZWwub3JnAAoJED2LAQed4NsGMywQAKXnzI0nOsJWCsRNhYaOvgR/xmEl
Tu/E+fN6aL/BGtIfkrdJzYRCa5UWONYMQuACvDhXarR1/Stkag9XyWY+rRTHK6In
rYGb2NmjKUsJ4mtZtpPY7lyMgizZJX63Ba8m+Np8U3dpHuCk2OncOJFszJAiPqoN
RbJiUNTT8F0/W827kvDcbdWc8iiXN75mqblFZQBSG71kiv/l/3Jsz/FE5980pGfv
XfZbokOKBGpEAnzHCt4wfodlTQxsezzbgkrzquVhosJYidXcl3VMnoJMfPFFJwIv
pxgIyrdUxgyuM3iqwymiXxJtv+wVUC9lTEgYp4KgIy0kj2ACe59u6wAcjSDoHWEu
pImhidGu0dZTrIltT4IE2WoqsFqtjkMCAM1DvLlgPS8GROL0IK0l9AnXAyCUoSYE
RMhYO3K9G6z0PGvNGJcxPttih8na/hLjvUwbFWUGlltadmYqSLA16MO4c3NOgqMR
RbLJ5K6c/tKe9ktW8f+FVJlcRnEebEbG9hzQLG5W/umEesxUQHFVe44nmCEJkyVB
tQdCXCqiBOcSoJC+pYceuGG/vUhX+Nmm+zMyI5pTwAvBL7Yx4Ef4HOIMlbKCLT6z
HsC/CtfIb1IEfNbKq+9nkHZRnO8lNAORJmyFzTwDYDQJWvNTKvDviJo5V7i9QfEm
0WVOr9qCIlOWJvGe
=T0vB
-----END PGP SIGNATURE-----
Merge tag 'kbuild-fixes-v5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
Pull Kbuild fixes from Masahiro Yamada:
- Search for <ncurses.h> in the default header path of HOSTCC
- Tweak the option order to be kind to old BSD awk
- Remove 'kvmconfig' and 'xenconfig' shorthands
- Fix documentation
* tag 'kbuild-fixes-v5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
Documentation: kbuild: Fix section reference
kconfig: remove 'kvmconfig' and 'xenconfig' shorthands
lib/raid6: Let $(UNROLL) rules work with macOS userland
kconfig: Support building mconf with vendor sysroot ncurses
kconfig: config script: add a little user help
MAINTAINERS: adjust GCC PLUGINS after gcc-plugin.sh removal
Fedora Rawhide has started including gcc 11,and the g++ compiler
throws a wobbly when it hits scripts/gcc-plugins:
HOSTCXX scripts/gcc-plugins/latent_entropy_plugin.so
In file included from /usr/include/c++/11/type_traits:35,
from /usr/lib/gcc/x86_64-redhat-linux/11/plugin/include/system.h:244,
from /usr/lib/gcc/x86_64-redhat-linux/11/plugin/include/gcc-plugin.h:28,
from scripts/gcc-plugins/gcc-common.h:7,
from scripts/gcc-plugins/latent_entropy_plugin.c:78:
/usr/include/c++/11/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO
C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
32 | #error This file requires compiler and library support \
In fact, it works just fine with c++11, which has been in gcc since 4.8,
and we now require 4.9 as a minimum.
Signed-off-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/82487.1609006918@turing-police
Changes the final fallback path in the ncurses locator for mconf
to support host compilers with a non-default sysroot.
This is similar to the hardcoded search for ncurses under
'/usr/include', but can support compilers that keep their default
header and library directories elsewhere.
For nconfig, do nothing because the only vendor compiler I'm aware
of with this layout (Apple Clang) ships an ncurses version that's too
old for nconfig anyway.
Signed-off-by: John Millikin <john@john-millikin.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Give the user a clue about the problem along with the 35 lines of
usage/help text.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: linux-kbuild@vger.kernel.org
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Commit 436e980e2e ("kbuild: don't hardcode depmod path") stopped
hard-coding the path of depmod, but in the process caused trouble for
distributions that had that /sbin location, but didn't have it in the
PATH (generally because /sbin is limited to the super-user path).
Work around it for now by just adding /sbin to the end of PATH in the
depmod.sh script.
Reported-and-tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Prefer strscpy over the deprecated strlcpy function.
Link: https://lkml.kernel.org/r/19fe91084890e2c16fe56f960de6c570a93fa99b.camel@perches.com
Signed-off-by: Joe Perches <joe@perches.com>
Requested-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull coccinelle updates from Julia Lawall.
* 'for-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/jlawall/linux:
scripts: coccicheck: Correct usage of make coccicheck
coccinelle: update expiring email addresses
coccinnelle: Remove ptr_ret script
kbuild: do not use scripts/ld-version.sh for checking spatch version
remove boolinit.cocci
The command "make coccicheck C=1 CHECK=scripts/coccicheck" results in the
error:
./scripts/coccicheck: line 65: -1: shift count out of range
This happens because every time the C variable is specified,
the shell arguments need to be "shifted" in order to take only
the last argument, which is the C file to test. These shell arguments
mostly comprise flags that have been set in the Makefile. However,
when coccicheck is specified in the make command as a rule, the
number of shell arguments is zero, thus passing the invalid value -1
to the shift command, resulting in an error.
Modify coccicheck to print correct usage of make coccicheck so as to
avoid the error.
Signed-off-by: Sumera Priyadarsini <sylphrenadin@gmail.com>
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
- Support only Qt5 for qconf
- Validate signal/slot connection at compile time of qconf
- Sanitize header includes
-----BEGIN PGP SIGNATURE-----
iQJJBAABCgAzFiEEbmPs18K1szRHjPqEPYsBB53g2wYFAl/iIc0VHG1hc2FoaXJv
eUBrZXJuZWwub3JnAAoJED2LAQed4NsGz4EQAJy1lXWki5It0yDhErvZAjlHJok/
wtr/2vATp73odFobm8g3fWEh/Tpwl4LFoIuU5dM5njKY1RG63v0jNN3QzrWvheHw
Ug5S1WtN7tqNDGLc2sgU80h148UUY12AlZGtw+YRQINFUU8xjqXMNbgdalikCNRb
FrEW0+g4mzqh3wTZIdK5i9jbh6XX8gisPNdG50yzClO47WuGXq259eoopdqrIRvb
n8K8T4XkdfmNaSiF9LuEIH26H+IPnyheMqm5xayCSlwLUxoBI5aJbEGVFXYF4TzK
pu5QWV2B63EWsGz/9MXDpDtHpj8XjIg8b1Rs8uJ1xcE7TB7furjyvIBfglj/oFId
46myaibsmLo72QNGBgozvtlcvEflOGqDw++zV+rdA3CWcncF0pKkT+FdOEJFHh31
HE5mnF2IjFzOoWbkD1lEJChaY1vw7lC+ZO6+wTUasTHUVOabgXr1RkJYuv+ABxq4
YzkUR+jCktNeMtlitjEzkUuSPgkjRNgUJ0B+pQbZOBLVHTkqg2obQU1yD8RIk3AT
qUFAbSoceN4pyyKBENyDDZFtphTX0NiP6yNzlGshYRPMMrmWOXaqjsH0QWZBTxRS
LQgyknBXVgIKrthcinf9FgEO70I0rmUJu88V/Zg4d0Oq4p6E1gGrtFPcJ6sOnKBT
O3mt06Pj2AP/RpJs
=Puqw
-----END PGP SIGNATURE-----
Merge tag 'kconfig-v5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
Pull Kconfig updates from Masahiro Yamada:
- Support only Qt5 for qconf
- Validate signal/slot connection at compile time of qconf
- Sanitize header includes
* tag 'kconfig-v5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
kconfig: doc: fix $(fileno) to $(filename)
kconfig: fix return value of do_error_if()
kconfig: clean up header inclusion
kconfig: qconf: show Qt version in the About dialog
kconfig: make lkc.h self-sufficient #include-wise
kconfig: qconf: convert to Qt5 new signal/slot connection syntax
kconfig: qconf: use a variable to pass packages to pkg-config
kconfig: qconf: drop Qt4 support
- Use /usr/bin/env for shebang lines in scripts
- Remove useless -Wnested-externs warning flag
- Update documents
- Refactor log handling in modpost
- Stop building modules without MODULE_LICENSE() tag
- Make the insane combination of 'static' and EXPORT_SYMBOL an error
- Improve genksyms to handle _Static_assert()
-----BEGIN PGP SIGNATURE-----
iQJJBAABCgAzFiEEbmPs18K1szRHjPqEPYsBB53g2wYFAl/iIY8VHG1hc2FoaXJv
eUBrZXJuZWwub3JnAAoJED2LAQed4NsGbfsP+gMv3F+ztqfYNoMNmZcj+fLh4zrA
8I3d0t0AoxovV1bsyVDk9nebsYLbDdsyCdHM1ZNFAFEpf9QLL8sxtpHvaaxy+rCq
PCmy+E6iO5B91oORhuqpYpcmmgPHf4RrpUcnEEiWOMrHE5giYbXz3AiqGAt/88J5
Y8yaPCQVhNJNkx73KHCMYLVp97xPGa5HvNrcskAueA8uG+FCRDFaIqFX+OYbGnmC
/3kVAJmX6i2kNPzvnXpAW6mTbI/z7+s/k5yRbEFYNUtJqN+BfaFadV8pyOGXQr1T
fwXVtXdWqVg7rbqupyVYItLHaOq2RBm4PJuee/8s7ooBI1y7U6N0HZCj+jES92ML
wuqEyED+lLzmxRyfhmrFH/5XhxacciO7dQb9Woe5FQ6QOm+tQPtwCnxwrSSAK4XU
k7CsJ+OMJI+JulFrgPuC/rcESjTAsgL2j4SDhsO0GLV+Qb/P9kXR88jt5eJygmSx
xZWpI+FUUY/Ihw648i2pkHGS/NmfOrT78X4nvbOWMDKOV02NEoMmLDYnZPUIoetn
yUo8+xSBp6n3aTy5TDtrMblNRUJwL9OzDlDiEjsPtNUJZ6sdQzFRsxJ7+FCw2Ley
rKN2r+i5FdyAq0LLHDhoEcJxFY7cj+yAsd0QqtBb0NZLgLsaPiP7w45CXRNpqkWG
BbK+F1E9jP8VfiZu
=+27V
-----END PGP SIGNATURE-----
Merge tag 'kbuild-v5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
Pull Kbuild updates from Masahiro Yamada:
- Use /usr/bin/env for shebang lines in scripts
- Remove useless -Wnested-externs warning flag
- Update documents
- Refactor log handling in modpost
- Stop building modules without MODULE_LICENSE() tag
- Make the insane combination of 'static' and EXPORT_SYMBOL an error
- Improve genksyms to handle _Static_assert()
* tag 'kbuild-v5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
Documentation/kbuild: Document platform dependency practises
Documentation/kbuild: Document COMPILE_TEST dependencies
genksyms: Ignore module scoped _Static_assert()
modpost: turn static exports into error
modpost: turn section mismatches to error from fatal()
modpost: change license incompatibility to error() from fatal()
modpost: turn missing MODULE_LICENSE() into error
modpost: refactor error handling and clarify error/fatal difference
modpost: rename merror() to error()
kbuild: don't hardcode depmod path
kbuild: doc: document subdir-y syntax
kbuild: doc: clarify the difference between extra-y and always-y
kbuild: doc: split if_changed explanation to a separate section
kbuild: doc: merge 'Special Rules' and 'Custom kbuild commands' sections
kbuild: doc: fix 'List directories to visit when descending' section
kbuild: doc: replace arch/$(ARCH)/ with arch/$(SRCARCH)/
kbuild: doc: update the description about kbuild Makefiles
Makefile.extrawarn: remove -Wnested-externs warning
tweewide: Fix most Shebang lines
$(error-if,...) is expanded to an empty string. Currently, it relies on
eval_clause() returning xstrdup("") when all attempts for expansion fail,
but the correct implementation is to make do_error_if() return xstrdup("").
Fixes: 1d6272e6fe ("kconfig: add 'info', 'warning-if', and 'error-if' built-in functions")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The C11 _Static_assert() keyword may be used at module scope, and we
need to teach genksyms about it to not abort with an error. We currently
have a growing number of static_assert() (but also direct usage of
_Static_assert()) users at module scope:
git grep -E '^_Static_assert\(|^static_assert\(' | grep -v '^tools' | wc -l
135
More recently, when enabling CONFIG_MODVERSIONS with CONFIG_KCSAN, we
observe a number of warnings:
WARNING: modpost: EXPORT symbol "<..all kcsan symbols..>" [vmlinux] [...]
When running a preprocessed source through 'genksyms -w' a number of
syntax errors point at usage of static_assert()s. In the case of
kernel/kcsan/encoding.h, new static_assert()s had been introduced which
used expressions that appear to cause genksyms to not even be able to
recover from the syntax error gracefully (as it appears was the case
previously).
Therefore, make genksyms ignore all _Static_assert() and the contained
expression. With the fix, usage of _Static_assert() no longer cause
"syntax error" all over the kernel, and the above modpost warnings for
KCSAN are gone, too.
Signed-off-by: Marco Elver <elver@google.com>
Acked-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Using EXPORT_SYMBOL*() on static functions is fundamentally wrong.
Modpost currently reports that as a warning, but clearly this is not a
pattern we should allow, and all in-tree occurences should have been
fixed by now. So, promote the warn() message to error() to make sure
this never happens again.
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Matthias Maennich <maennich@google.com>
Signed-off-by: Quentin Perret <qperret@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
There is code that reports static EXPORT_SYMBOL a few lines below.
It is not a good idea to bail out here.
I renamed sec_mismatch_fatal to sec_mismatch_warn_only (with logical
inversion) to match to CONFIG_SECTION_MISMATCH_WARN_ONLY.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Change fatal() to error() to continue running to report more possible
issues.
There is no difference in the fact that modpost will fail anyway.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
We have 3 log functions. fatal() is special because it lets modpost bail
out immediately. The difference between warn() and error() is the only
prefix parts ("WARNING:" vs "ERROR:").
In my understanding, the expected handling of error() is to propagate
the return code of the function to the exit code of modpost, as
check_exports() etc. already does. This is a good manner in general
because we should display as many error messages as possible in a
single run of modpost.
What is annoying about fatal() is that it kills modpost at the first
error. People would need to run Kbuild again and again until they fix
all errors.
But, unfortunately, people tend to do:
"This case should not be allowed. Let's replace warn() with fatal()."
One of the reasons is probably it is tedious to manually hoist the error
code to the main() function.
This commit refactors error() so any single call for it automatically
makes modpost return the error code.
I also added comments in modpost.h for warn(), error(), and fatal().
Please use fatal() only when you have a strong reason to do so.
For example:
- Memory shortage (i.e. malloc() etc. has failed)
- The ELF file is broken, and there is no point to continue parsing
- Something really odd has happened
For general coding errors, please use error().
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: Quentin Perret <qperret@google.com>
The log function names, warn(), merror(), fatal() are inconsistent.
Commit 2a11665945 ("kbuild: distinguish between errors and warnings
in modpost") intentionally chose merror() to avoid the conflict with
the library function error(). See man page of error(3).
But, we are already causing the conflict with warn() because it is also
a library function. See man page of warn(3). err() would be a problem
for the same reason.
The common technique to work around name conflicts is to use macros.
For example:
/* in a header */
#define error(fmt, ...) __error(fmt, ##__VA_ARGS__)
#define warn(fmt, ...) __warn(fmt, ##__VA_ARGS__)
/* function definition */
void __error(const char *fmt, ...)
{
<our implementation>
}
void __warn(const char *fmt, ...)
{
<our implementation>
}
In this way, we can implement our own warn() and error(), still we can
include <error.h> and <err.h> with no problem.
And, commit 93c95e526a ("modpost: rework and consolidate logging
interface") already did that.
Since the log functions are all macros, we can use error() without
causing "conflicting types" errors.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
- Clean up gcc plugin builds now that GCC must be 4.9+ (Masahiro Yamada)
- Update MAINTAINERS (Kees Cook)
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEpcP2jyKd1g9yPm4TiXL039xtwCYFAl/ZGR0ACgkQiXL039xt
wCZ4yRAAr21CUfPBeMDbhlf3JLS/coDMzGodoybJfMr3T3g3cz3E2UGiR+YJ8yg2
nX690+VAA04jwb+C87vJXE7X5KcbSisBKwn7jvkc9jAtu23t5s8/x7oReekr4g0P
K6RbRI/4orR4mbxlu+f2Naxsjpx5SZas1HkJMhW9cis8am3tv0T6v23rvlQDXhWC
UJU1/e/MytISFI5pR6SzSC6MgPG/P0P3M69GC8qu/Bgm+Tw0BeBIfJFTT2r1HNND
GpYX707yAV/kkAv6NwoDy4Ls50L0XhVU72qC+/blC0a/GZdjEGDLS8S5G3KOg1qM
SUGB0nNQBYaCO4WTfl0Oj5WGdkwzhOY8FzI2uAkwKUYA6d5SVJRAlrbM3GJEOfCr
z8mwmq4mX2hkkRP4jgbXgG3tHrW0Evli/a7xcYLALX6iAr8Jo+iWzkSPXb2eFj4J
PaWMvVm6CvnMrQl6jYww5dtvXD2bDy0h4KtjDqRpTUkjttGsmLqQjRkkDkcJ3bAz
olS+HGHAw1slWmdZHwknERHTfqUi0SEb9VKBjpzvaR5dZmJ1WnQ9q2x9UQzR3cYb
hbjqHRxVUMy6xq9UjvN9CjQAAtPdo6z9ohVzfkKiyR1fLxmb09Zr58iks196NYCm
AptY51216KJAYWuBAQG/bUeraGB3LFfVobzLUP9LoklHkjipOHw=
=pF48
-----END PGP SIGNATURE-----
Merge tag 'gcc-plugins-v5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux
Pull gcc-plugins updates from Kees Cook:
- Clean up gcc plugin builds now that GCC must be 4.9+ (Masahiro
Yamada)
- Update MAINTAINERS (Kees Cook)
* tag 'gcc-plugins-v5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
MAINTAINERS: Drop inactive gcc-plugins maintainer
gcc-plugins: simplify GCC plugin-dev capability test
gcc-plugins: remove code for GCC versions older than 4.9
Instead of doing if/endif blocks with cc-option calls in the UBSAN
Makefile, move all the tests into Kconfig and use the Makefile to collect
the results.
Link: https://lkml.kernel.org/r/20201203004437.389959-3-keescook@chromium.org
Link: https://lore.kernel.org/lkml/CAHk-=wjPasyJrDuwDnpHJS2TuQfExwe=px-SzLeN8GFMAQJPmQ@mail.gmail.com/
Signed-off-by: Kees Cook <keescook@chromium.org>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: George Popescu <georgepope@android.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Marco Elver <elver@google.com>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Michal Marek <michal.lkml@markovi.net>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Peter Oberparleiter <oberpar@linux.ibm.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Patch series "Clean up UBSAN Makefile", v2.
This series attempts to address the issues seen with UBSAN's object-size
sanitizer causing problems under GCC. In the process, the Kconfig and
Makefile are refactored to do all the cc-option calls in the Kconfig.
Additionally start to detangle -Wno-maybe-uninitialized, disable
UBSAN_TRAP under COMPILE_TEST for wider build coverage, and expand the
libusan tests.
This patch (of 7):
In commit 78a5255ffb ("Stop the ad-hoc games with
-Wno-maybe-initialized") -Wmaybe-uninitialized was disabled globally, so
keeping the disabling logic here too doesn't make sense.
Link: https://lkml.kernel.org/r/20201203004437.389959-1-keescook@chromium.org
Link: https://lkml.kernel.org/r/20201203004437.389959-2-keescook@chromium.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Michal Marek <michal.lkml@markovi.net>
Cc: Nathan Chancellor <natechancellor@gmail.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Marco Elver <elver@google.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: George Popescu <georgepope@android.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Peter Oberparleiter <oberpar@linux.ibm.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
checkpatch reports a false TYPO_SPELLING warning for some words containing
an apostrophe when run with --codespell option.
A false positive is "doesn't". Occurrence of the word causes checkpatch
to emit the following warning:
"WARNING: 'doesn'' may be misspelled - perhaps 'doesn't'?"
Modify the regex pattern to be more in line with the codespell default
word matching regex. This fixes the word capture and avoids the false
warning.
In addition, highlight the misspelled word location by adding a caret
below the word.
[akpm@linux-foundation.org: make matched misspelling more obvious, per Joe]
Link: https://lkml.kernel.org/r/09c24ef1aa2f1c4fe909d76f5426f08780b9d81c.camel@perches.com
Link: https://lkml.kernel.org/r/20201201190729.169733-1-dwaipayanray1@gmail.com
Signed-off-by: Dwaipayan Ray <dwaipayanray1@gmail.com>
Suggested-by: Joe Perches <joe@perches.com>
Reported-by: Peilin Ye <yepeilin.cs@gmail.com>
Acked-by: Joe Perches <joe@perches.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit log lines starting with '#' are dropped by git as comments.
Add a check to emit a warning for these lines.
Also add a --fix option to insert a space before the leading '#' in
such lines.
Link: https://lkml.kernel.org/r/20201202205740.127986-1-dwaipayanray1@gmail.com
Signed-off-by: Dwaipayan Ray <dwaipayanray1@gmail.com>
Suggested-by: Joe Perches <joe@perches.com>
Suggested-by: Peilin Ye <yepeilin.cs@gmail.com>
Tested-by: Peilin Ye <yepeilin.cs@gmail.com>
Acked-by: Joe Perches <joe@perches.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Masahiro Yamada