aboutsummaryrefslogtreecommitdiff
path: root/kernel/gcov/Kconfig
AgeCommit message (Collapse)AuthorFilesLines
2021-12-02gcov: Remove compiler version checkNathan Chancellor1-1/+0
The minimum supported version of LLVM has been raised to 11.0.0, meaning this check is always true, so it can be dropped. Signed-off-by: Nathan Chancellor <[email protected]> Reviewed-by: Miguel Ojeda <[email protected]> Reviewed-by: Mark Brown <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2021-06-22Kconfig: Introduce ARCH_WANTS_NO_INSTR and CC_HAS_NO_PROFILE_FN_ATTRNick Desaulniers1-0/+1
We don't want compiler instrumentation to touch noinstr functions, which are annotated with the no_profile_instrument_function function attribute. Add a Kconfig test for this and make GCOV depend on it, and in the future, PGO. If an architecture is using noinstr, it should denote that via this Kconfig value. That makes Kconfigs that depend on noinstr able to express dependencies in an architecturally agnostic way. Cc: Masahiro Yamada <[email protected]> Link: https://lore.kernel.org/lkml/[email protected]/ Link: https://lore.kernel.org/lkml/YMcssV%[email protected]/ Suggested-by: Nathan Chancellor <[email protected]> Suggested-by: Peter Zijlstra <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Reviewed-by: Peter Oberparleiter <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Acked-by: Mark Rutland <[email protected]> Acked-by: Heiko Carstens <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-05-07gcov: clang: drop support for clang-10 and olderNick Desaulniers1-0/+1
LLVM changed the expected function signatures for llvm_gcda_start_file() and llvm_gcda_emit_function() in the clang-11 release. Drop the older implementations and require folks to upgrade their compiler if they're interested in GCOV support. Link: https://reviews.llvm.org/rGcdd683b516d147925212724b09ec6fb792a40041 Link: https://reviews.llvm.org/rG13a633b438b6500ecad9e4f936ebadf3411d0f44 Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Nick Desaulniers <[email protected]> Suggested-by: Nathan Chancellor <[email protected]> Acked-by: Peter Oberparleiter <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Reviewed-by: Fangrui Song <[email protected]> Cc: Prasad Sodagudi <[email protected]> Cc: Johannes Berg <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-02-05init/gcov: allow CONFIG_CONSTRUCTORS on UML to fix module gcovJohannes Berg1-1/+1
On ARCH=um, loading a module doesn't result in its constructors getting called, which breaks module gcov since the debugfs files are never registered. On the other hand, in-kernel constructors have already been called by the dynamic linker, so we can't call them again. Get out of this conundrum by allowing CONFIG_CONSTRUCTORS to be selected, but avoiding the in-kernel constructor calls. Also remove the "if !UML" from GCOV selecting CONSTRUCTORS now, since we really do want CONSTRUCTORS, just not kernel binary ones. Link: https://lkml.kernel.org/r/20210120172041.c246a2cac2fb.I1358f584b76f1898373adfed77f4462c8705b736@changeid Signed-off-by: Johannes Berg <[email protected]> Reviewed-by: Peter Oberparleiter <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Jessica Yu <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-09-11gcov: add support for GCC 10.1Peter Oberparleiter1-1/+0
Using gcov to collect coverage data for kernels compiled with GCC 10.1 causes random malfunctions and kernel crashes. This is the result of a changed GCOV_COUNTERS value in GCC 10.1 that causes a mismatch between the layout of the gcov_info structure created by GCC profiling code and the related structure used by the kernel. Fix this by updating the in-kernel GCOV_COUNTERS value. Also re-enable config GCOV_KERNEL for use with GCC 10. Reported-by: Colin Ian King <[email protected]> Reported-by: Leon Romanovsky <[email protected]> Signed-off-by: Peter Oberparleiter <[email protected]> Tested-by: Leon Romanovsky <[email protected]> Tested-and-Acked-by: Colin Ian King <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-09-04gcov: Disable gcov build with GCC 10Leon Romanovsky1-0/+1
GCOV built with GCC 10 doesn't initialize n_function variable. This produces different kernel panics as was seen by Colin in Ubuntu and me in FC 32. As a workaround, let's disable GCOV build for broken GCC 10 version. Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1891288 Link: https://lore.kernel.org/lkml/[email protected] Link: https://lore.kernel.org/lkml/CAHk-=whbijeSdSvx-Xcr0DPMj0BiwhJ+uiNnDSVZcr_h_kg7UA@mail.gmail.com/ Cc: Colin Ian King <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-06-14treewide: replace '---help---' in Kconfig files with 'help'Masahiro Yamada1-2/+2
Since commit 84af7a6194e4 ("checkpatch: kconfig: prefer 'help' over '---help---'"), the number of '---help---' has been gradually decreasing, but there are still more than 2400 instances. This commit finishes the conversion. While I touched the lines, I also fixed the indentation. There are a variety of indentation styles found. a) 4 spaces + '---help---' b) 7 spaces + '---help---' c) 8 spaces + '---help---' d) 1 space + 1 tab + '---help---' e) 1 tab + '---help---' (correct indentation) f) 1 tab + 1 space + '---help---' g) 1 tab + 2 spaces + '---help---' In order to convert all of them to 1 tab + 'help', I ran the following commend: $ find . -name 'Kconfig*' | xargs sed -i 's/^[[:space:]]*---help---/\thelp/' Signed-off-by: Masahiro Yamada <[email protected]>
2020-04-16gcov: Remove old GCC 3.4 supportWill Deacon1-24/+0
The kernel requires at least GCC 4.8 in order to build, and so there is no need to cater for the pre-4.7 gcov format. Remove the obsolete code. Acked-by: Peter Oberparleiter <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2020-01-19Revert "um: Enable CONFIG_CONSTRUCTORS"Johannes Berg1-1/+1
This reverts commit 786b2384bf1c ("um: Enable CONFIG_CONSTRUCTORS"). There are two issues with this commit, uncovered by Anton in tests on some (Debian) systems: 1) I completely forgot to call any constructors if CONFIG_CONSTRUCTORS isn't set. Don't recall now if it just wasn't needed on my system, or if I never tested this case. 2) With that fixed, it works - with CONFIG_CONSTRUCTORS *unset*. If I set CONFIG_CONSTRUCTORS, it fails again, which isn't totally unexpected since whatever wanted to run is likely to have to run before the kernel init etc. that calls the constructors in this case. Basically, some constructors that gcc emits (libc has?) need to run very early during init; the failure mode otherwise was that the ptrace fork test already failed: ---------------------- $ ./linux mem=512M Core dump limits : soft - 0 hard - NONE Checking that ptrace can change system call numbers...check_ptrace : child exited with exitcode 6, while expecting 0; status 0x67f Aborted ---------------------- Thinking more about this, it's clear that we simply cannot support CONFIG_CONSTRUCTORS in UML. All the cases we need now (gcov, kasan) involve not use of the __attribute__((constructor)), but instead some constructor code/entry generated by gcc. Therefore, we cannot distinguish between kernel constructors and system constructors. Thus, revert this commit. Cc: [email protected] [5.4+] Fixes: 786b2384bf1c ("um: Enable CONFIG_CONSTRUCTORS") Reported-by: Anton Ivanov <[email protected]> Signed-off-by: Johannes Berg <[email protected]> Acked-by: Anton Ivanov <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
2019-09-15um: Enable CONFIG_CONSTRUCTORSJohannes Berg1-1/+1
We do need to call the constructors for *modules*, and at least for KASAN in the future, we must call even the kernel constructors only later when the kernel has been initialized. Instead of relying on libc to call them, emit an empty section for libc and let the kernel's CONSTRUCTORS code do the rest of the job. Tested that it indeed doesn't work in modules, and does work after the fixes in both, with a few functions with __attribute__((constructor)) in both dynamic and static builds. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
2019-05-21treewide: Add SPDX license identifier - Makefile/KconfigThomas Gleixner1-0/+1
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 <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-05-14gcov: clang supportGreg Hackmann1-1/+2
LLVM uses profiling data that's deliberately similar to GCC, but has a very different way of exporting that data. LLVM calls llvm_gcov_init() once per module, and provides a couple of callbacks that we can use to ask for more data. We care about the "writeout" callback, which in turn calls back into compiler-rt/this module to dump all the gathered coverage data to disk: llvm_gcda_start_file() llvm_gcda_emit_function() llvm_gcda_emit_arcs() llvm_gcda_emit_function() llvm_gcda_emit_arcs() [... repeats for each function ...] llvm_gcda_summary_info() llvm_gcda_end_file() This design is much more stateless and unstructured than gcc's, and is intended to run at process exit. This forces us to keep some local state about which module we're dealing with at the moment. On the other hand, it also means we don't depend as much on how LLVM represents profiling data internally. See LLVM's lib/Transforms/Instrumentation/GCOVProfiling.cpp for more details on how this works, particularly GCOVProfiler::emitProfileArcs(), GCOVProfiler::insertCounterWriteout(), and GCOVProfiler::insertFlush(). [[email protected]: coding-style fixes] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Hackmann <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Signed-off-by: Tri Vo <[email protected]> Co-developed-by: Nick Desaulniers <[email protected]> Co-developed-by: Tri Vo <[email protected]> Tested-by: Trilok Soni <[email protected]> Tested-by: Prasad Sodagudi <[email protected]> Tested-by: Tri Vo <[email protected]> Tested-by: Daniel Mentz <[email protected]> Tested-by: Petri Gynther <[email protected]> Reviewed-by: Peter Oberparleiter <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-06-08gcov: remove CONFIG_GCOV_FORMAT_AUTODETECTMasahiro Yamada1-12/+5
CONFIG_GCOV_FORMAT_AUTODETECT compiles either gcc_3_4.c or gcc_4_7.c according to your GCC version. We can achieve the equivalent behavior by setting reasonable dependency with the knowledge of the compiler version. If GCC older than 4.7 is used, GCOV_FORMAT_3_4 is the default, but users are still allowed to select GCOV_FORMAT_4_7 in case the newer format is back-ported. On the other hand, If GCC 4.7 or newer is used, there is no reason to use GCOV_FORMAT_3_4, so it should be hidden. If you downgrade the compiler to GCC 4.7 or older, oldconfig/syncconfig will display a prompt for the choice because GCOV_FORMAT_3_4 becomes visible as a new symbol. Signed-off-by: Masahiro Yamada <[email protected]> Acked-by: Peter Oberparleiter <[email protected]> Reviewed-by: Kees Cook <[email protected]>
2016-05-10gcov: disable for COMPILE_TESTArnd Bergmann1-0/+1
Enabling gcov is counterproductive to compile testing: it significantly increases the kernel image size, compile time, and it produces lots of false positive "may be used uninitialized" warnings as the result of missed optimizations. This is in line with how UBSAN_SANITIZE_ALL and PROFILE_ALL_BRANCHES work, both of which have similar problems. With an ARM allmodconfig kernel, I see the build time drop from 283 minutes CPU time to 225 minutes, and the vmlinux size drops from 43MB to 26MB. Signed-off-by: Arnd Bergmann <[email protected]> Acked-by: Peter Oberparleiter <[email protected]> Signed-off-by: Michal Marek <[email protected]>
2014-12-13gcov: enable GCOV_PROFILE_ALL from ARCH KconfigsRiku Voipio1-1/+4
Following the suggestions from Andrew Morton and Stephen Rothwell, Dont expand the ARCH list in kernel/gcov/Kconfig. Instead, define a ARCH_HAS_GCOV_PROFILE_ALL bool which architectures can enable. set ARCH_HAS_GCOV_PROFILE_ALL on Architectures where it was previously allowed + ARM64 which I tested. Signed-off-by: Riku Voipio <[email protected]> Cc: Peter Oberparleiter <[email protected]> Cc: Stephen Rothwell <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-10-29gcov: add ARM64 to GCOV_PROFILE_ALLRiku Voipio1-1/+1
Following up the arm testing of gcov, turns out gcov on ARM64 works fine as well. Only change needed is adding ARM64 to Kconfig depends. Tested with qemu and mach-virt Signed-off-by: Riku Voipio <[email protected]> Acked-by: Peter Oberparleiter <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-09-26ARM: 8153/1: Enable gcov support on the ARM architectureVincent Sanders1-1/+1
Enable gcov support for ARM based on original patches by David Singleton and George G. Davis Riku - updated to patch to current mainline kernel. The patch has been submitted in 2010, 2012 - for symmetry, now in 2014 too. https://lwn.net/Articles/390419/ http://marc.info/?l=linux-arm-kernel&m=133823081813044 v2: remove arch/arm/kernel from gcov disabled files Cc: Andrey Ryabinin <[email protected]> Cc: Naresh Kamboju <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Signed-off-by: Riku Voipio <[email protected]> Signed-off-by: Vincent Sanders <[email protected]> Signed-off-by: Russell King <[email protected]>
2013-11-13gcov: compile specific gcov implementation based on gcc versionFrantisek Hrbata1-0/+30
Compile the correct gcov implementation file for the specific gcc version. Signed-off-by: Frantisek Hrbata <[email protected]> Cc: Jan Stancek <[email protected]> Cc: Kees Cook <[email protected]> Acked-by: Peter Oberparleiter <[email protected]> Cc: Rusty Russell <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Andy Gospodarek <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2013-01-11kernel/gcov: remove depends on CONFIG_EXPERIMENTALKees Cook1-1/+1
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a while now and is almost always enabled by default. As agreed during the Linux kernel summit, remove it from any "depends on" lines in Kconfigs. Cc: WANG Cong <[email protected]> Signed-off-by: Kees Cook <[email protected]> Acked-by: Peter Oberparleiter <[email protected]>
2011-07-26gcov: disable CONSTRUCTORS for UMLVitaliy Ivanov1-1/+1
Selecting GCOV for UML causing configuration mismatch: warning: (GCOV_KERNEL) selects CONSTRUCTORS which has unmet direct dependencies (!UML) Constructors are not needed for UML. Signed-off-by: Vitaliy Ivanov <[email protected]> Cc: Peter Oberparleiter <[email protected]> Acked-by: Richard Weinberger <[email protected]> Acked-by: WANG Cong <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2011-06-15gcov: disable CONFIG_CONSTRUCTORS when not needed by CONFIG_GCOV_KERNELJosh Triplett1-1/+2
CONFIG_CONSTRUCTORS controls support for running constructor functions at kernel init time. According to commit b99b87f70c7785ab ("kernel: constructor support"), gcov (CONFIG_GCOV_KERNEL) needs this. However, CONFIG_CONSTRUCTORS currently defaults to y, with no option to disable it, and CONFIG_GCOV_KERNEL depends on it. Instead, default it to n and have CONFIG_GCOV_KERNEL select it, so that the normal case of CONFIG_GCOV_KERNEL=n will result in CONFIG_CONSTRUCTORS=n. Observed in the short list of =y values in a minimal kernel configuration. Signed-off-by: Josh Triplett <[email protected]> Acked-by: WANG Cong <[email protected]> Acked-by: Peter Oberparleiter <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2011-02-15sh: Enable CONFIG_GCOV_PROFILE_ALL for shChris Smith1-1/+1
This patch enables gcov kernel profiling over the whole kernel for sh. Profiling of specific files individually already worked. A handful of files have to be explicitly excluded from the profiling to avoid breaking things, notably pmb.c. Signed-off-by: Chris Smith <[email protected]> Signed-off-by: Stuart Menefy <[email protected]> Signed-off-by: Paul Mundt <[email protected]>
2009-09-21microblaze: Enable GCOV_PROFILE_ALLMichal Simek1-1/+1
Signed-off-by: Michal Simek <[email protected]>
2009-08-20powerpc: Enable GCOVMichael Ellerman1-1/+1
Make it possible to enable GCOV code coverage measurement on powerpc. Lightly tested on 64-bit, seems to work as expected. Signed-off-by: Michael Ellerman <[email protected]> Signed-off-by: Benjamin Herrenschmidt <[email protected]>
2009-06-18gcov: enable GCOV_PROFILE_ALL for x86_64Peter Oberparleiter1-1/+1
Enable gcov profiling of the entire kernel on x86_64. Required changes include disabling profiling for: * arch/kernel/acpi/realmode and arch/kernel/boot/compressed: not linked to main kernel * arch/vdso, arch/kernel/vsyscall_64 and arch/kernel/hpet: profiling causes segfaults during boot (incompatible context) Signed-off-by: Peter Oberparleiter <[email protected]> Cc: Andi Kleen <[email protected]> Cc: Huang Ying <[email protected]> Cc: Li Wei <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Heiko Carstens <[email protected]> Cc: Martin Schwidefsky <[email protected]> Cc: Rusty Russell <[email protected]> Cc: WANG Cong <[email protected]> Cc: Sam Ravnborg <[email protected]> Cc: Jeff Dike <[email protected]> Cc: Al Viro <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2009-06-18gcov: add gcov profiling infrastructurePeter Oberparleiter1-0/+48
Enable the use of GCC's coverage testing tool gcov [1] with the Linux kernel. gcov may be useful for: * debugging (has this code been reached at all?) * test improvement (how do I change my test to cover these lines?) * minimizing kernel configurations (do I need this option if the associated code is never run?) The profiling patch incorporates the following changes: * change kbuild to include profiling flags * provide functions needed by profiling code * present profiling data as files in debugfs Note that on some architectures, enabling gcc's profiling option "-fprofile-arcs" for the entire kernel may trigger compile/link/ run-time problems, some of which are caused by toolchain bugs and others which require adjustment of architecture code. For this reason profiling the entire kernel is initially restricted to those architectures for which it is known to work without changes. This restriction can be lifted once an architecture has been tested and found compatible with gcc's profiling. Profiling of single files or directories is still available on all platforms (see config help text). [1] http://gcc.gnu.org/onlinedocs/gcc/Gcov.html Signed-off-by: Peter Oberparleiter <[email protected]> Cc: Andi Kleen <[email protected]> Cc: Huang Ying <[email protected]> Cc: Li Wei <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Heiko Carstens <[email protected]> Cc: Martin Schwidefsky <[email protected]> Cc: Rusty Russell <[email protected]> Cc: WANG Cong <[email protected]> Cc: Sam Ravnborg <[email protected]> Cc: Jeff Dike <[email protected]> Cc: Al Viro <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.