lineno : line number of the debug statement
module : module that contains the debug statement
function : function that contains the debug statement
- flags : '=p' means the line is turned 'on' for printing
- format : the format used for the debug statement
+ flags : '=p' means the line is turned 'on' for printing
+ format : the format used for the debug statement
From a live system:
of the number 28. It makes the kernel image slightly larger
(about 3KB), but can make the kernel logs easier to read.
+config DEBUG_BUGVERBOSE
+ bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT
+ depends on BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE)
+ default y
+ help
+ Say Y here to make BUG() panics output the file name and line number
+ of the BUG call as well as the EIP and oops trace. This aids
+ debugging but costs about 70-100K of memory.
+
endmenu # "printk and dmesg options"
menu "Compile-time checks and compiler options"
bool "Compile the kernel with debug info"
depends on DEBUG_KERNEL && !COMPILE_TEST
help
- If you say Y here the resulting kernel image will include
+ If you say Y here the resulting kernel image will include
debugging info resulting in a larger kernel image.
This adds debug symbols to the kernel and modules (gcc -g), and
is needed if you intend to use kernel crashdump or binary object
get_wchan() and suchlike.
config READABLE_ASM
- bool "Generate readable assembler code"
- depends on DEBUG_KERNEL
- help
- Disable some compiler optimizations that tend to generate human unreadable
- assembler output. This may make the kernel slightly slower, but it helps
- to keep kernel developers who have to stare a lot at assembler listings
- sane.
-
-config DEBUG_FS
- bool "Debug Filesystem"
+ bool "Generate readable assembler code"
+ depends on DEBUG_KERNEL
help
- debugfs is a virtual file system that kernel developers use to put
- debugging files into. Enable this option to be able to read and
- write to these files.
-
- For detailed documentation on the debugfs API, see
- Documentation/filesystems/.
-
- If unsure, say N.
+ Disable some compiler optimizations that tend to generate human unreadable
+ assembler output. This may make the kernel slightly slower, but it helps
+ to keep kernel developers who have to stare a lot at assembler listings
+ sane.
config HEADERS_INSTALL
bool "Install uapi headers to usr/include"
user-space program samples. It is also needed by some features such
as uapi header sanity checks.
-config HEADERS_CHECK
- bool "Run sanity checks on uapi headers when building 'all'"
- depends on HEADERS_INSTALL
- help
- This option will run basic sanity checks on uapi headers when
- building the 'all' target, for example, ensure that they do not
- attempt to include files which were not exported, etc.
-
- If you're making modifications to header files which are
- relevant for userspace, say 'Y'.
-
config OPTIMIZE_INLINING
def_bool y
help
endmenu # "Compiler options"
+menu "Generic Kernel Debugging Instruments"
+
config MAGIC_SYSRQ
bool "Magic SysRq key"
depends on !UML
This option allows you to decide whether you want to enable the
magic SysRq key.
+config DEBUG_FS
+ bool "Debug Filesystem"
+ help
+ debugfs is a virtual file system that kernel developers use to put
+ debugging files into. Enable this option to be able to read and
+ write to these files.
+
+ For detailed documentation on the debugfs API, see
+ Documentation/filesystems/.
+
+ If unsure, say N.
+
+source "lib/Kconfig.kgdb"
+
+source "lib/Kconfig.ubsan"
+
+endmenu
+
config DEBUG_KERNEL
bool "Kernel debugging"
help
config DEBUG_OBJECTS_ENABLE_DEFAULT
int "debug_objects bootup default value (0-1)"
- range 0 1
- default "1"
- depends on DEBUG_OBJECTS
- help
- Debug objects boot parameter default value
+ range 0 1
+ default "1"
+ depends on DEBUG_OBJECTS
+ help
+ Debug objects boot parameter default value
config DEBUG_SLAB
bool "Debug slab memory allocations"
This option will slow down process creation somewhat.
+config SCHED_STACK_END_CHECK
+ bool "Detect stack corruption on calls to schedule()"
+ depends on DEBUG_KERNEL
+ default n
+ help
+ This option checks for a stack overrun on calls to schedule().
+ If the stack end location is found to be over written always panic as
+ the content of the corrupted region can no longer be trusted.
+ This is to ensure no erroneous behaviour occurs which could result in
+ data corruption or a sporadic crash at a later stage once the region
+ is examined. The runtime overhead introduced is minimal.
+
config DEBUG_VM
bool "Debug VM"
depends on DEBUG_KERNEL
help
Enable this to turn on extended checks in the virtual-memory system
- that may impact performance.
+ that may impact performance.
If unsure, say N.
endmenu # "Memory Debugging"
-config ARCH_HAS_KCOV
- bool
- help
- An architecture should select this when it can successfully
- build and run with CONFIG_KCOV. This typically requires
- disabling instrumentation for some early boot code.
-
-config CC_HAS_SANCOV_TRACE_PC
- def_bool $(cc-option,-fsanitize-coverage=trace-pc)
-
-config KCOV
- bool "Code coverage for fuzzing"
- depends on ARCH_HAS_KCOV
- depends on CC_HAS_SANCOV_TRACE_PC || GCC_PLUGINS
- select DEBUG_FS
- select GCC_PLUGIN_SANCOV if !CC_HAS_SANCOV_TRACE_PC
- help
- KCOV exposes kernel code coverage information in a form suitable
- for coverage-guided fuzzing (randomized testing).
-
- If RANDOMIZE_BASE is enabled, PC values will not be stable across
- different machines and across reboots. If you need stable PC values,
- disable RANDOMIZE_BASE.
-
- For more details, see Documentation/dev-tools/kcov.rst.
-
-config KCOV_ENABLE_COMPARISONS
- bool "Enable comparison operands collection by KCOV"
- depends on KCOV
- depends on $(cc-option,-fsanitize-coverage=trace-cmp)
- help
- KCOV also exposes operands of every comparison in the instrumented
- code along with operand sizes and PCs of the comparison instructions.
- These operands can be used by fuzzing engines to improve the quality
- of fuzzing coverage.
-
-config KCOV_INSTRUMENT_ALL
- bool "Instrument all code by default"
- depends on KCOV
- default y
- help
- If you are doing generic system call fuzzing (like e.g. syzkaller),
- then you will want to instrument the whole kernel and you should
- say y here. If you are doing more targeted fuzzing (like e.g.
- filesystem fuzzing with AFL) then you will want to enable coverage
- for more specific subsets of files, and should say n here.
-
config DEBUG_SHIRQ
bool "Debug shared IRQ handlers"
depends on DEBUG_KERNEL
Drivers ought to be able to handle interrupts coming in at those
points; some don't and need to be caught.
-menu "Debug Lockups and Hangs"
+menu "Debug Oops, Lockups and Hangs"
+
+config PANIC_ON_OOPS
+ bool "Panic on Oops"
+ help
+ Say Y here to enable the kernel to panic when it oopses. This
+ has the same effect as setting oops=panic on the kernel command
+ line.
+
+ This feature is useful to ensure that the kernel does not do
+ anything erroneous after an oops which could result in data
+ corruption or other issues.
+
+ Say N if unsure.
+
+config PANIC_ON_OOPS_VALUE
+ int
+ range 0 1
+ default 0 if !PANIC_ON_OOPS
+ default 1 if PANIC_ON_OOPS
+
+config PANIC_TIMEOUT
+ int "panic timeout"
+ default 0
+ help
+ Set the timeout value (in seconds) until a reboot occurs when the
+ the kernel panics. If n = 0, then we wait forever. A timeout
+ value n > 0 will wait n seconds before rebooting, while a timeout
+ value n < 0 will reboot immediately.
config LOCKUP_DETECTOR
bool
endmenu # "Debug lockups and hangs"
-config PANIC_ON_OOPS
- bool "Panic on Oops"
- help
- Say Y here to enable the kernel to panic when it oopses. This
- has the same effect as setting oops=panic on the kernel command
- line.
-
- This feature is useful to ensure that the kernel does not do
- anything erroneous after an oops which could result in data
- corruption or other issues.
-
- Say N if unsure.
-
-config PANIC_ON_OOPS_VALUE
- int
- range 0 1
- default 0 if !PANIC_ON_OOPS
- default 1 if PANIC_ON_OOPS
-
-config PANIC_TIMEOUT
- int "panic timeout"
- default 0
- help
- Set the timeout value (in seconds) until a reboot occurs when the
- the kernel panics. If n = 0, then we wait forever. A timeout
- value n > 0 will wait n seconds before rebooting, while a timeout
- value n < 0 will reboot immediately.
+menu "Scheduler Debugging"
config SCHED_DEBUG
bool "Collect scheduler debugging info"
application, you can say N to avoid the very slight overhead
this adds.
-config SCHED_STACK_END_CHECK
- bool "Detect stack corruption on calls to schedule()"
- depends on DEBUG_KERNEL
- default n
- help
- This option checks for a stack overrun on calls to schedule().
- If the stack end location is found to be over written always panic as
- the content of the corrupted region can no longer be trusted.
- This is to ensure no erroneous behaviour occurs which could result in
- data corruption or a sporadic crash at a later stage once the region
- is examined. The runtime overhead introduced is minimal.
+endmenu
config DEBUG_TIMEKEEPING
bool "Enable extra timekeeping sanity checking"
config HAVE_DEBUG_BUGVERBOSE
bool
-config DEBUG_BUGVERBOSE
- bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT
- depends on BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE)
- default y
- help
- Say Y here to make BUG() panics output the file name and line number
- of the BUG call as well as the EIP and oops trace. This aids
- debugging but costs about 70-100K of memory.
+menu "Debug kernel data structures"
config DEBUG_LIST
bool "Debug linked list manipulation"
This is a relatively cheap check but if you care about maximum
performance, say N.
+config BUG_ON_DATA_CORRUPTION
+ bool "Trigger a BUG when data corruption is detected"
+ select DEBUG_LIST
+ help
+ Select this option if the kernel should BUG when it encounters
+ data corruption in kernel memory structures when they get checked
+ for validity.
+
+ If unsure, say N.
+
+endmenu
+
config DEBUG_CREDENTIALS
bool "Debug credential management"
depends on DEBUG_KERNEL
be impacted.
config DEBUG_BLOCK_EXT_DEVT
- bool "Force extended block device numbers and spread them"
+ bool "Force extended block device numbers and spread them"
depends on DEBUG_KERNEL
depends on BLOCK
default n
Say N if your are unsure.
+config LATENCYTOP
+ bool "Latency measuring infrastructure"
+ depends on DEBUG_KERNEL
+ depends on STACKTRACE_SUPPORT
+ depends on PROC_FS
+ select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM && !ARC && !X86
+ select KALLSYMS
+ select KALLSYMS_ALL
+ select STACKTRACE
+ select SCHEDSTATS
+ select SCHED_DEBUG
+ help
+ Enable this option if you want to use the LatencyTOP tool
+ to find out which userspace is blocking on what kernel operations.
+
+source "kernel/trace/Kconfig"
+
+config PROVIDE_OHCI1394_DMA_INIT
+ bool "Remote debugging over FireWire early on boot"
+ depends on PCI && X86
+ help
+ If you want to debug problems which hang or crash the kernel early
+ on boot and the crashing machine has a FireWire port, you can use
+ this feature to remotely access the memory of the crashed machine
+ over FireWire. This employs remote DMA as part of the OHCI1394
+ specification which is now the standard for FireWire controllers.
+
+ With remote DMA, you can monitor the printk buffer remotely using
+ firescope and access all memory below 4GB using fireproxy from gdb.
+ Even controlling a kernel debugger is possible using remote DMA.
+
+ Usage:
+
+ If ohci1394_dma=early is used as boot parameter, it will initialize
+ all OHCI1394 controllers which are found in the PCI config space.
+
+ As all changes to the FireWire bus such as enabling and disabling
+ devices cause a bus reset and thereby disable remote DMA for all
+ devices, be sure to have the cable plugged and FireWire enabled on
+ the debugging host before booting the debug target for debugging.
+
+ This code (~1k) is freed after boot. By then, the firewire stack
+ in charge of the OHCI-1394 controllers should be used instead.
+
+ See Documentation/debugging-via-ohci1394.txt for more information.
+
+source "lib/kunit/Kconfig"
+
config NOTIFIER_ERROR_INJECTION
tristate "Notifier error injection"
depends on DEBUG_KERNEL
help
Provide stacktrace filter for fault-injection capabilities
-config LATENCYTOP
- bool "Latency measuring infrastructure"
- depends on DEBUG_KERNEL
- depends on STACKTRACE_SUPPORT
- depends on PROC_FS
- select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM && !ARC && !X86
- select KALLSYMS
- select KALLSYMS_ALL
- select STACKTRACE
- select SCHEDSTATS
- select SCHED_DEBUG
- help
- Enable this option if you want to use the LatencyTOP tool
- to find out which userspace is blocking on what kernel operations.
+endmenu # "Kernel Testing and Coverage"
-source "kernel/trace/Kconfig"
+menu "Kernel Testing and Coverage"
-config PROVIDE_OHCI1394_DMA_INIT
- bool "Remote debugging over FireWire early on boot"
- depends on PCI && X86
+config ARCH_HAS_KCOV
+ bool
help
- If you want to debug problems which hang or crash the kernel early
- on boot and the crashing machine has a FireWire port, you can use
- this feature to remotely access the memory of the crashed machine
- over FireWire. This employs remote DMA as part of the OHCI1394
- specification which is now the standard for FireWire controllers.
+ An architecture should select this when it can successfully
+ build and run with CONFIG_KCOV. This typically requires
+ disabling instrumentation for some early boot code.
- With remote DMA, you can monitor the printk buffer remotely using
- firescope and access all memory below 4GB using fireproxy from gdb.
- Even controlling a kernel debugger is possible using remote DMA.
+config CC_HAS_SANCOV_TRACE_PC
+ def_bool $(cc-option,-fsanitize-coverage=trace-pc)
- Usage:
- If ohci1394_dma=early is used as boot parameter, it will initialize
- all OHCI1394 controllers which are found in the PCI config space.
+config KCOV
+ bool "Code coverage for fuzzing"
+ depends on ARCH_HAS_KCOV
+ depends on CC_HAS_SANCOV_TRACE_PC || GCC_PLUGINS
+ select DEBUG_FS
+ select GCC_PLUGIN_SANCOV if !CC_HAS_SANCOV_TRACE_PC
+ help
+ KCOV exposes kernel code coverage information in a form suitable
+ for coverage-guided fuzzing (randomized testing).
- As all changes to the FireWire bus such as enabling and disabling
- devices cause a bus reset and thereby disable remote DMA for all
- devices, be sure to have the cable plugged and FireWire enabled on
- the debugging host before booting the debug target for debugging.
+ If RANDOMIZE_BASE is enabled, PC values will not be stable across
+ different machines and across reboots. If you need stable PC values,
+ disable RANDOMIZE_BASE.
- This code (~1k) is freed after boot. By then, the firewire stack
- in charge of the OHCI-1394 controllers should be used instead.
+ For more details, see Documentation/dev-tools/kcov.rst.
- See Documentation/debugging-via-ohci1394.txt for more information.
+config KCOV_ENABLE_COMPARISONS
+ bool "Enable comparison operands collection by KCOV"
+ depends on KCOV
+ depends on $(cc-option,-fsanitize-coverage=trace-cmp)
+ help
+ KCOV also exposes operands of every comparison in the instrumented
+ code along with operand sizes and PCs of the comparison instructions.
+ These operands can be used by fuzzing engines to improve the quality
+ of fuzzing coverage.
-source "lib/kunit/Kconfig"
+config KCOV_INSTRUMENT_ALL
+ bool "Instrument all code by default"
+ depends on KCOV
+ default y
+ help
+ If you are doing generic system call fuzzing (like e.g. syzkaller),
+ then you will want to instrument the whole kernel and you should
+ say y here. If you are doing more targeted fuzzing (like e.g.
+ filesystem fuzzing with AFL) then you will want to enable coverage
+ for more specific subsets of files, and should say n here.
menuconfig RUNTIME_TESTING_MENU
bool "Runtime Testing"
memtest=17, mean do 17 test patterns.
If you are unsure how to answer this question, answer N.
-config BUG_ON_DATA_CORRUPTION
- bool "Trigger a BUG when data corruption is detected"
- select DEBUG_LIST
- help
- Select this option if the kernel should BUG when it encounters
- data corruption in kernel memory structures when they get checked
- for validity.
-
- If unsure, say N.
-
source "samples/Kconfig"
-source "lib/Kconfig.kgdb"
-
-source "lib/Kconfig.ubsan"
-
config ARCH_HAS_DEVMEM_IS_ALLOWED
bool
If in doubt, say Y.
+menu "$(SRCARCH) Debugging"
+
source "arch/$(SRCARCH)/Kconfig.debug"
+endmenu
+
config HYPERV_TESTING
bool "Microsoft Hyper-V driver testing"
default n
projects / linux-2.6-microblaze.git / blobdiff