2019-11-01 13:45:29 +01:00
|
|
|
# Debug configuration options
|
2015-09-18 15:13:17 -04:00
|
|
|
|
|
|
|
# Copyright (c) 2015 Wind River Systems, Inc.
|
2017-01-18 17:01:01 -08:00
|
|
|
# SPDX-License-Identifier: Apache-2.0
|
2015-09-18 15:13:17 -04:00
|
|
|
|
2020-02-06 11:59:54 +08:00
|
|
|
|
2018-11-02 07:12:07 -04:00
|
|
|
menu "System Monitoring Options"
|
|
|
|
|
2020-08-22 12:41:24 -04:00
|
|
|
menuconfig THREAD_ANALYZER
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Thread analyzer"
|
2020-08-22 12:41:24 -04:00
|
|
|
select INIT_STACKS
|
|
|
|
select THREAD_MONITOR
|
|
|
|
select THREAD_STACK_INFO
|
2020-12-12 08:41:27 -05:00
|
|
|
select THREAD_RUNTIME_STATS
|
2020-08-22 12:41:24 -04:00
|
|
|
help
|
|
|
|
Enable thread analyzer functionality and all the required modules.
|
|
|
|
This module may be used to debug thread configuration issues, e.g.
|
|
|
|
stack size configuration to find stack overflow or to find stacks
|
|
|
|
which may be optimized.
|
|
|
|
|
|
|
|
if THREAD_ANALYZER
|
|
|
|
module = THREAD_ANALYZER
|
|
|
|
module-str = thread analyzer
|
2022-03-24 14:10:29 +00:00
|
|
|
source "subsys/logging/Kconfig.template.log_config"
|
2020-08-22 12:41:24 -04:00
|
|
|
|
|
|
|
choice
|
|
|
|
prompt "Thread analysis print mode"
|
|
|
|
|
|
|
|
config THREAD_ANALYZER_USE_LOG
|
|
|
|
bool "Use logger output"
|
|
|
|
select LOG
|
|
|
|
help
|
|
|
|
Use logger output to print thread information.
|
|
|
|
|
|
|
|
config THREAD_ANALYZER_USE_PRINTK
|
|
|
|
bool "Use printk function"
|
|
|
|
help
|
|
|
|
Use kernel printk function to print thread information.
|
|
|
|
|
|
|
|
endchoice
|
|
|
|
|
2022-01-28 15:47:50 +01:00
|
|
|
config THREAD_ANALYZER_ISR_STACK_USAGE
|
|
|
|
bool "Analyze interrupt stacks usage"
|
|
|
|
default y
|
|
|
|
|
2020-08-22 12:41:24 -04:00
|
|
|
config THREAD_ANALYZER_RUN_UNLOCKED
|
|
|
|
bool "Run analysis with interrupts unlocked"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
The thread analysis takes quite a long time.
|
|
|
|
Every thread it finds is analyzed word by word to find any that
|
|
|
|
does not match the magic number.
|
|
|
|
Normally while thread are analyzed the k_thread_foreach function
|
|
|
|
is used.
|
|
|
|
While this is a safe run from the thread list perspective it may lock
|
|
|
|
the interrupts for a long time - long enough to disconnect when
|
|
|
|
Bluetooth communication is used.
|
|
|
|
Setting this flag will force thread analyzer to use
|
|
|
|
the k_thread_foreach_unlocked function.
|
|
|
|
This will allow the interrupts to be processed while the thread is
|
|
|
|
analyzed.
|
|
|
|
For the limitation of such configuration see the k_thread_foreach
|
|
|
|
documentation.
|
|
|
|
|
|
|
|
config THREAD_ANALYZER_AUTO
|
|
|
|
bool "Run periodic thread analysis in a thread"
|
|
|
|
help
|
|
|
|
Run the thread analyzer automatically, without the need to add
|
|
|
|
any code to the application.
|
|
|
|
Thread analysis would be called periodically.
|
|
|
|
|
|
|
|
if THREAD_ANALYZER_AUTO
|
|
|
|
|
|
|
|
config THREAD_ANALYZER_AUTO_INTERVAL
|
|
|
|
int "Thread analysis interval"
|
|
|
|
default 60
|
|
|
|
range 5 3600
|
|
|
|
help
|
|
|
|
The time in seconds to call thread analyzer periodic printing function.
|
|
|
|
|
|
|
|
config THREAD_ANALYZER_AUTO_STACK_SIZE
|
|
|
|
int "Stack size for the periodic thread analysis thread"
|
2022-02-09 12:29:10 +01:00
|
|
|
default 2048 if THREAD_ANALYZER_USE_LOG && LOG_MODE_IMMEDIATE && NO_OPTIMIZATIONS
|
2021-05-10 09:52:08 +02:00
|
|
|
default 1024
|
2020-08-22 12:41:24 -04:00
|
|
|
|
|
|
|
endif # THREAD_ANALYZER_AUTO
|
|
|
|
|
|
|
|
endif # THREAD_ANALYZER
|
|
|
|
|
|
|
|
|
2018-11-02 07:12:07 -04:00
|
|
|
endmenu
|
|
|
|
|
2017-04-27 14:04:44 -07:00
|
|
|
menu "Debugging Options"
|
|
|
|
|
|
|
|
config DEBUG
|
|
|
|
bool "Build kernel with debugging enabled"
|
|
|
|
help
|
2017-12-13 10:08:21 -05:00
|
|
|
Build a kernel suitable for debugging. Right now, this option
|
|
|
|
only disables optimization, more debugging variants can be selected
|
|
|
|
from here to allow more debugging.
|
2017-04-27 14:04:44 -07:00
|
|
|
|
2022-04-21 10:38:32 -04:00
|
|
|
config GPROF
|
|
|
|
bool "Generate profiling information"
|
|
|
|
depends on ARCH_POSIX
|
|
|
|
help
|
|
|
|
Generate call graph profile data for the application that can be
|
|
|
|
analyzed with gprof
|
|
|
|
|
2018-05-29 15:16:29 -07:00
|
|
|
config ASAN
|
|
|
|
bool "Build with address sanitizer"
|
|
|
|
depends on ARCH_POSIX
|
|
|
|
help
|
2019-10-04 00:54:00 +02:00
|
|
|
Builds Zephyr with Address Sanitizer enabled. This is currently
|
|
|
|
only supported by boards based on the posix architecture, and requires a
|
|
|
|
recent-ish compiler with the ``-fsanitize=address`` command line option,
|
|
|
|
and the libasan library.
|
|
|
|
|
2019-10-27 14:50:25 +01:00
|
|
|
Note that at exit leak detection is disabled for 64-bit boards when
|
|
|
|
GCC is used due to potential risk of a deadlock in libasan.
|
|
|
|
This behavior can be changes by adding leak_check_at_exit=1 to the
|
|
|
|
environment variable ASAN_OPTIONS.
|
|
|
|
|
cmake: Update CONFIG_ASAN support
This had bitrotten a bit, and didn't build as shipped. Current
libasan implementations want -fsanitize=address passed as a linker
argument too. We have grown a "lld" linker variant that needs the
same cmake treatment as the "ld" binutils one, but never got it. But
the various flags had been cut/pasted around to different places, with
slightly different forms. That's really sort of a mess, as sanitizer
support was only ever support with host toolchains for native_posix
(and AFAICT no one anywhere has made this work on cross compilers in
an embedded environment). And the separate "gcc" vs. "llvm" layers
were silly, as there has only ever been one API for this feature (from
LLVM, then picked up compatibly by gcc).
Pull this stuff out and just do it in one place in the posix arch for
simplicity.
Also recent sanitizers are trying to add instrumentation padding
around data that we use linker trickery to pack tightly
(c.f. SYS_INIT, STRUCT_SECTION_ITERABLE) and we need a way
("__noasan") to turn that off. Actually for gcc, it was enough to
just make the records const (already true for most of them, except a
native_posix init struct), but clang apparently isn't smart enough.
Finally, add an ASAN_RECOVER kconfig that enables the use of
"halt_on_error=0" in $ASAN_OPTIONS, which continues execution past the
first error.
Signed-off-by: Andy Ross <andyross@google.com>
2022-08-09 17:57:42 -07:00
|
|
|
config ASAN_RECOVER
|
|
|
|
bool "Continue after sanitizer errors"
|
|
|
|
depends on ASAN
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
The default behavior of compiler sanitizers is to exit after
|
|
|
|
the first error. Set this to y to enable the code to
|
|
|
|
continue, which can be useful if a code base has known
|
|
|
|
unsuppressed errors. You will also need to set
|
|
|
|
"halt_on_error=0" in your ASAN_OPTIONS environment variable
|
|
|
|
at runtime.
|
|
|
|
|
2019-11-03 13:39:33 +01:00
|
|
|
config ASAN_NOP_DLCLOSE
|
|
|
|
bool "Override host OS dlclose() with a NOP"
|
|
|
|
default y if HAS_SDL
|
kconfig: Replace some single-symbol 'if's with 'depends on'
I think people might be reading differences into 'if' and 'depends on'
that aren't there, like maybe 'if' being needed to "hide" a symbol,
while 'depends on' just adds a dependency.
There are no differences between 'if' and 'depends on'. 'if' is just a
shorthand for 'depends on'. They work the same when it comes to creating
implicit menus too.
The way symbols get "hidden" is through their dependencies not being
satisfied ('if'/'depends on' get copied up as a dependency on the
prompt).
Since 'if' and 'depends on' are the same, an 'if' with just a single
symbol in it can be replaced with a 'depends on'. IMO, it's best to
avoid 'if' there as a style choice too, because it confuses people into
thinking there's deep Kconfig magic going on that requires 'if'.
Going for 'depends on' can also remove some nested 'if's, which
generates nicer symbol information and docs, because nested 'if's really
are so simple/dumb that they just add the dependencies from both 'if's
to all symbols within.
Replace a bunch of single-symbol 'if's with 'depends on' to despam the
Kconfig files a bit and make it clearer how things work. Also do some
other minor related dependency refactoring.
The replacement isn't complete. Will fix up the rest later. Splitting it
a bit to make it more manageable.
(Everything above is true for choices, menus, and comments as well.)
Detected by tweaking the Kconfiglib parsing code. It's impossible to
detect after parsing, because 'if' turns into 'depends on'.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2020-02-08 03:45:50 +01:00
|
|
|
depends on ASAN
|
2019-11-03 13:39:33 +01:00
|
|
|
help
|
|
|
|
Override host OS dlclose() with a NOP.
|
|
|
|
|
|
|
|
This NOP implementation is needed as workaround for a known limitation in
|
|
|
|
LSAN (leak sanitizer) that if dlcose is called before performing the leak
|
|
|
|
check, "<unknown module>" is reported in the stack traces during the leak
|
|
|
|
check and these can not be suppressed, see
|
|
|
|
https://github.com/google/sanitizers/issues/89 for more info.
|
|
|
|
|
2019-10-04 00:54:00 +02:00
|
|
|
config UBSAN
|
|
|
|
bool "Build with undefined behavior sanitizer"
|
|
|
|
depends on ARCH_POSIX
|
|
|
|
help
|
|
|
|
Builds Zephyr with Undefined Behavior Sanitizer enabled.
|
|
|
|
This is currently only supported by boards based on the posix
|
|
|
|
architecture, and requires a recent-ish compiler with the
|
|
|
|
``-fsanitize=undefined`` command line option.
|
2018-05-29 15:16:29 -07:00
|
|
|
|
2022-08-16 11:42:53 -07:00
|
|
|
config MSAN
|
|
|
|
bool "Build with memory sanitizer"
|
|
|
|
depends on ARCH_POSIX
|
|
|
|
help
|
|
|
|
Builds Zephyr with the LLVM MemorySanitizer enabled. Works
|
|
|
|
only on the posix architecture currently, and only with host
|
|
|
|
compilers recent enough to support the feature (currently
|
|
|
|
clang on x86_64 only). It cannot be used in tandem with
|
|
|
|
CONFIG_ASAN due to clang limitations. You must choose one
|
|
|
|
or the other (but can combine it with CONFIG_UBSAN if you
|
|
|
|
like)
|
|
|
|
|
2017-04-27 14:04:44 -07:00
|
|
|
config STACK_USAGE
|
|
|
|
bool "Generate stack usage information"
|
|
|
|
help
|
2017-12-13 10:08:21 -05:00
|
|
|
Generate an extra file that specifies the maximum amount of stack used,
|
|
|
|
on a per-function basis.
|
2017-04-27 14:04:44 -07:00
|
|
|
|
2017-05-11 13:29:15 -07:00
|
|
|
config STACK_SENTINEL
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Stack sentinel"
|
2018-05-10 14:48:40 -05:00
|
|
|
select THREAD_STACK_INFO
|
2021-05-28 14:17:37 +02:00
|
|
|
depends on MULTITHREADING
|
2018-05-10 14:48:40 -05:00
|
|
|
depends on !USERSPACE
|
2017-05-11 13:29:15 -07:00
|
|
|
help
|
2017-12-13 10:08:21 -05:00
|
|
|
Store a magic value at the lowest addresses of a thread's stack.
|
|
|
|
Periodically check that this value is still present and kill the
|
|
|
|
thread gracefully if it isn't. This is currently checked in four
|
|
|
|
places:
|
|
|
|
|
|
|
|
1) Upon any context switch for the outgoing thread
|
|
|
|
2) Any hardware interrupt that doesn't context switch, the check is
|
|
|
|
performed for the interrupted thread
|
|
|
|
3) When a thread returns from its entry point
|
|
|
|
4) When a thread calls k_yield() but doesn't context switch
|
|
|
|
|
|
|
|
This feature doesn't prevent corruption and the system may be
|
|
|
|
in an unusable state. However, given the bizarre behavior associated
|
|
|
|
with stack overflows, knowledge that this is happening is very
|
|
|
|
useful.
|
|
|
|
|
|
|
|
This feature is intended for those systems which lack hardware support
|
|
|
|
for stack overflow protection, or have insufficient system resources
|
|
|
|
to use that hardware support.
|
2017-05-11 13:29:15 -07:00
|
|
|
|
2017-04-27 14:04:44 -07:00
|
|
|
config PRINTK
|
2018-07-12 13:26:29 +02:00
|
|
|
bool "Send printk() to console"
|
2017-04-27 14:04:44 -07:00
|
|
|
default y
|
|
|
|
help
|
2017-12-13 10:08:21 -05:00
|
|
|
This option directs printk() debugging output to the supported
|
|
|
|
console device, rather than suppressing the generation
|
|
|
|
of printk() output entirely. Output is sent immediately, without
|
|
|
|
any mutual exclusion or buffering.
|
2017-04-27 14:04:44 -07:00
|
|
|
|
2017-10-10 16:01:49 -07:00
|
|
|
config PRINTK_BUFFER_SIZE
|
2018-07-12 13:26:29 +02:00
|
|
|
int "printk() buffer size"
|
2017-10-10 16:01:49 -07:00
|
|
|
depends on PRINTK
|
|
|
|
depends on USERSPACE
|
|
|
|
default 32
|
|
|
|
help
|
2017-12-13 10:08:21 -05:00
|
|
|
If userspace is enabled, printk() calls are buffered so that we do
|
|
|
|
not have to make a system call for every character emitted. Specify
|
|
|
|
the size of this buffer.
|
2017-10-10 16:01:49 -07:00
|
|
|
|
2017-04-27 14:04:44 -07:00
|
|
|
config EARLY_CONSOLE
|
2018-07-12 13:26:29 +02:00
|
|
|
bool "Send stdout at the earliest stage possible"
|
2017-04-27 14:04:44 -07:00
|
|
|
help
|
2017-12-13 10:08:21 -05:00
|
|
|
This option will enable stdout as early as possible, for debugging
|
|
|
|
purpose. For instance, in case of STDOUT_CONSOLE being set it will
|
|
|
|
initialize its driver earlier than normal, in order to get the stdout
|
|
|
|
sent through the console at the earliest stage possible.
|
2017-04-27 14:04:44 -07:00
|
|
|
|
|
|
|
config ASSERT
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "__ASSERT() macro"
|
2018-05-24 13:02:08 -07:00
|
|
|
default y if TEST
|
2017-04-27 14:04:44 -07:00
|
|
|
help
|
2017-12-13 10:08:21 -05:00
|
|
|
This enables the __ASSERT() macro in the kernel code. If an assertion
|
2019-09-14 23:40:03 -07:00
|
|
|
fails, the policy for what to do is controlled by the implementation
|
|
|
|
of the assert_post_action() function, which by default will trigger
|
|
|
|
a fatal error.
|
|
|
|
|
|
|
|
Disabling this option will cause assertions to compile to nothing,
|
|
|
|
improving performance and system footprint.
|
2017-04-27 14:04:44 -07:00
|
|
|
|
2022-03-14 13:56:07 +01:00
|
|
|
if ASSERT
|
|
|
|
|
2017-04-27 14:04:44 -07:00
|
|
|
config ASSERT_LEVEL
|
2018-07-12 13:26:29 +02:00
|
|
|
int "__ASSERT() level"
|
2017-04-27 14:04:44 -07:00
|
|
|
default 2
|
|
|
|
range 0 2
|
|
|
|
help
|
2017-12-13 10:08:21 -05:00
|
|
|
This option specifies the assertion level used by the __ASSERT()
|
|
|
|
macro. It can be set to one of three possible values:
|
2017-04-27 14:04:44 -07:00
|
|
|
|
2017-12-13 10:08:21 -05:00
|
|
|
Level 0: off
|
|
|
|
Level 1: on + warning in every file that includes __assert.h
|
|
|
|
Level 2: on + no warning
|
2017-04-27 14:04:44 -07:00
|
|
|
|
2019-12-13 11:24:56 +01:00
|
|
|
config SPIN_VALIDATE
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Spinlock validation"
|
2021-04-15 10:45:08 +02:00
|
|
|
depends on MULTITHREADING
|
2021-01-12 15:27:55 +08:00
|
|
|
depends on MP_NUM_CPUS <= 4
|
2019-12-13 11:24:56 +01:00
|
|
|
default y if !FLASH || FLASH_SIZE > 32
|
|
|
|
help
|
|
|
|
There's a spinlock validation framework available when asserts are
|
|
|
|
enabled. It adds a relatively hefty overhead (about 3k or so) to
|
|
|
|
kernel code size, don't use on platforms known to be small.
|
|
|
|
|
2022-09-30 13:54:48 -05:00
|
|
|
config SPIN_LOCK_TIME_LIMIT
|
|
|
|
int "Spin lock holding time limit in cycles"
|
|
|
|
default 0
|
|
|
|
depends on SPIN_VALIDATE
|
|
|
|
depends on SYSTEM_CLOCK_LOCK_FREE_COUNT
|
|
|
|
help
|
|
|
|
Assert at the time of unlocking the number of system clock cycles
|
|
|
|
the lock has been held is less than the configured value. Requires
|
|
|
|
the timer driver sys_clock_get_cycles_32() be lock free.
|
|
|
|
|
2022-03-25 09:40:29 +01:00
|
|
|
endif # ASSERT
|
|
|
|
|
|
|
|
config FORCE_NO_ASSERT
|
|
|
|
bool "Force-disable no assertions"
|
|
|
|
help
|
|
|
|
This boolean option disables Zephyr assertion testing even
|
|
|
|
in circumstances (twister) where it is enabled via
|
|
|
|
CFLAGS and not Kconfig. Added solely to be able to work
|
|
|
|
around compiler bugs for specific tests.
|
|
|
|
|
2019-12-20 16:16:12 +01:00
|
|
|
config ASSERT_VERBOSE
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Verbose assertions"
|
2019-12-20 16:16:12 +01:00
|
|
|
default y
|
|
|
|
help
|
|
|
|
This option enables printing an assert message with information about
|
|
|
|
the assertion that occurred. This includes printing the location,
|
|
|
|
the conditional expression and additional message specific to the
|
|
|
|
assert.
|
|
|
|
|
2019-10-11 14:21:40 +02:00
|
|
|
config ASSERT_NO_FILE_INFO
|
|
|
|
bool "Disable file info for asserts"
|
|
|
|
help
|
|
|
|
This option removes the name and the path of the source file
|
|
|
|
in which the assertion occurred. Enabling this will save
|
|
|
|
target code space, and thus may be necessary for tiny targets.
|
|
|
|
|
2019-12-09 14:07:10 +01:00
|
|
|
config ASSERT_NO_COND_INFO
|
|
|
|
bool "Disable condition info for asserts"
|
|
|
|
help
|
|
|
|
This option removes the assert condition from the printed assert
|
|
|
|
message. Enabling this will save target code space, and thus may be
|
|
|
|
necessary for tiny targets. It is recommended to disable condition
|
|
|
|
info before disabling file info since the condition can be found in
|
|
|
|
the source using file info.
|
|
|
|
|
2019-12-20 16:21:52 +01:00
|
|
|
config ASSERT_NO_MSG_INFO
|
|
|
|
bool "Disable message for asserts"
|
|
|
|
help
|
|
|
|
This option removes the additional message from the printed assert.
|
|
|
|
Enabling this will save target code space, and thus may be
|
|
|
|
necessary for tiny targets. It is recommended to disable message
|
|
|
|
before disabling file info since the message can be found in the
|
|
|
|
source using file info.
|
|
|
|
|
2022-08-05 01:45:03 +09:00
|
|
|
config ASSERT_TEST
|
|
|
|
bool "Assert test mode"
|
|
|
|
help
|
|
|
|
This option enables the assert test mode, which allows the assert
|
|
|
|
post action handler to return (i.e. not abort) when the asserted
|
|
|
|
condition is false. The tests that validate the assert feature may
|
|
|
|
select this option to allow the test to proceed by implementing a
|
|
|
|
custom assert post action hook.
|
|
|
|
|
2017-04-27 14:04:44 -07:00
|
|
|
config OVERRIDE_FRAME_POINTER_DEFAULT
|
2018-07-12 13:26:29 +02:00
|
|
|
bool "Override compiler defaults for -fomit-frame-pointer"
|
2017-04-27 14:04:44 -07:00
|
|
|
help
|
2017-12-13 10:08:21 -05:00
|
|
|
Omitting the frame pointer prevents the compiler from putting the stack
|
|
|
|
frame pointer into a register. Saves a few instructions in function
|
|
|
|
prologues/epilogues and frees up a register for general-purpose use,
|
|
|
|
which can provide good performance improvements on register-constrained
|
|
|
|
architectures like x86. On some architectures (including x86) omitting
|
|
|
|
frame pointers impedes debugging as local variables are harder to
|
|
|
|
locate. At -O1 and above gcc will enable -fomit-frame-pointer
|
|
|
|
automatically but only if the architecture does not require if for
|
|
|
|
effective debugging.
|
|
|
|
|
|
|
|
Choose Y if you want to override the default frame pointer behavior
|
|
|
|
of your compiler, otherwise choose N.
|
2017-04-27 14:04:44 -07:00
|
|
|
|
|
|
|
config OMIT_FRAME_POINTER
|
2018-07-12 13:26:29 +02:00
|
|
|
bool "Omit frame pointer"
|
2017-04-27 14:04:44 -07:00
|
|
|
depends on OVERRIDE_FRAME_POINTER_DEFAULT
|
|
|
|
help
|
2017-12-13 10:08:21 -05:00
|
|
|
Choose Y for best performance. On some architectures (including x86)
|
2022-03-16 21:07:43 +00:00
|
|
|
this will favor code size and performance over debuggability.
|
2017-04-27 14:04:44 -07:00
|
|
|
|
2017-12-13 10:08:21 -05:00
|
|
|
Choose N in you wish to retain the frame pointer. This option may
|
|
|
|
be useful if your application uses runtime backtracing and does not
|
|
|
|
support parsing unwind tables.
|
2017-04-27 14:04:44 -07:00
|
|
|
|
2017-12-13 10:08:21 -05:00
|
|
|
If unsure, disable OVERRIDE_FRAME_POINTER_DEFAULT to allow the compiler
|
|
|
|
to adopt sensible defaults for your architecture.
|
2015-09-18 15:13:17 -04:00
|
|
|
|
2017-11-22 13:41:31 -05:00
|
|
|
|
2016-04-11 17:44:11 -04:00
|
|
|
#
|
|
|
|
# Generic Debugging Options
|
|
|
|
#
|
|
|
|
config DEBUG_INFO
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "System debugging information"
|
2016-04-11 17:44:11 -04:00
|
|
|
help
|
2018-01-29 12:51:13 -08:00
|
|
|
This option enables the addition of various information that can be
|
|
|
|
used by debuggers in debugging the system, or enable additional
|
|
|
|
debugging information to be reported at runtime.
|
2016-04-11 17:44:11 -04:00
|
|
|
|
2018-01-29 12:51:13 -08:00
|
|
|
config EXCEPTION_STACK_TRACE
|
|
|
|
bool "Attempt to print stack traces upon exceptions"
|
|
|
|
default y
|
|
|
|
depends on PRINTK
|
|
|
|
depends on DEBUG_INFO
|
|
|
|
depends on !OMIT_FRAME_POINTER
|
|
|
|
help
|
|
|
|
If the architecture fatal handling code supports it, attempt to
|
|
|
|
print a stack trace of function memory addresses when an
|
|
|
|
exception is reported.
|
debug: add target GDB server
The GDB server implements a set of GDB commands, such as read/write
memory, read/write registers, connect/detach, breakpoints, single-step,
continue. It is not OS-aware, and thus provides a 'system-level'
debugging environment, where the system stops when debugging (such as
handling a breakpoint or single-stepping).
It currently only works over a serial line, taking over the
uart_console. If target code prints over the console, the GDB server
intecepts them and does not send the characters directly over the serial
line, but rather wraps them in a packet handled by the GDB client.
Change-Id: Ic4b82e81b5a575831c01af7b476767234fbf74f7
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
2016-04-11 17:51:39 -04:00
|
|
|
|
2017-02-01 10:21:21 -08:00
|
|
|
#
|
|
|
|
# Miscellaneous debugging options
|
|
|
|
#
|
2021-03-11 19:51:35 +01:00
|
|
|
config DEBUG_THREAD_INFO
|
|
|
|
bool "Thread awareness support"
|
2020-05-08 21:34:26 +03:00
|
|
|
depends on !SMP
|
2017-02-01 10:21:21 -08:00
|
|
|
select THREAD_MONITOR
|
2018-10-21 09:37:21 -05:00
|
|
|
select THREAD_NAME
|
2017-02-01 10:21:21 -08:00
|
|
|
help
|
2021-03-11 19:51:35 +01:00
|
|
|
This option exports an array of offsets to kernel structs to allow
|
|
|
|
for debugger RTOS plugins to determine the state of running threads.
|
2017-04-27 14:04:44 -07:00
|
|
|
|
2020-08-07 10:47:37 -07:00
|
|
|
rsource "coredump/Kconfig"
|
2019-02-14 12:38:42 +01:00
|
|
|
endmenu
|
2020-05-21 16:55:28 -07:00
|
|
|
|
|
|
|
config GDBSTUB
|
|
|
|
bool "GDB remote serial protocol support [EXPERIMENTAL]"
|
|
|
|
depends on ARCH_HAS_GDBSTUB
|
2021-10-15 14:33:33 +02:00
|
|
|
select EXPERIMENTAL
|
2020-05-21 16:55:28 -07:00
|
|
|
help
|
|
|
|
This option enable support the target using GDB, or any other
|
|
|
|
application that supports GDB protocol.
|
|
|
|
|
|
|
|
if GDBSTUB
|
|
|
|
|
|
|
|
choice
|
|
|
|
prompt "GDB backend"
|
|
|
|
|
|
|
|
config GDBSTUB_SERIAL_BACKEND
|
|
|
|
bool "Use serial backend"
|
|
|
|
depends on SERIAL
|
|
|
|
help
|
2021-10-20 20:53:04 -05:00
|
|
|
Use serial as backend for GDB
|
2020-05-21 16:55:28 -07:00
|
|
|
|
|
|
|
endchoice
|
|
|
|
|
2021-10-12 14:51:09 -07:00
|
|
|
config GDBSTUB_BUF_SZ
|
|
|
|
int "GDB backend send/receive buffer size (in bytes)"
|
|
|
|
default 256
|
|
|
|
help
|
|
|
|
This specifies the size (in bytes) of the send/receive buffer
|
|
|
|
for GDB backend. This needs to be big enough to hold one
|
|
|
|
full GDB packet at a time.
|
2020-05-21 16:55:28 -07:00
|
|
|
|
|
|
|
endif
|
2022-12-06 19:20:34 +01:00
|
|
|
|
|
|
|
config SEGGER_DEBUGMON
|
|
|
|
bool "Use Segger's J-Link debug monitor implementation"
|
|
|
|
depends on CORTEX_M_DEBUG_MONITOR_HOOK
|
|
|
|
help
|
|
|
|
This option will enable Segger's implementation of
|
|
|
|
the debug monitor interrupt, overriding the
|
|
|
|
default z_arm_debug_monitor symbol.
|