Replace the open-coded test of K_USER in a thread's user_options with
k_thread_is_user_thread(). No functional change.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The in-memory backend keeps the dump in RAM so that it can be read
after a warm reboot. With a write-back data cache, the dump or the
cleared canaries can still be in the cache at reset and get lost: a
new dump goes missing, or an erased dump is reported as valid again.
Flush the data cache once the dump is written and when it is erased.
The end canary commits the dump: write back the header and the used
part of the buffer first, then write and flush the canary, so that a
reset during the write-back cannot leave a partial dump marked valid.
-ENOTSUP (no data cache under Zephyr control) and -EAGAIN (data cache
disabled) leave nothing to write back and are not errors. Other flush
errors are logged. A new dump is not written if the old one cannot be
invalidated, and not committed if it cannot be written back. The
erase and invalidate commands return the error.
Tested with the in_memory scenario of tests/subsys/debug/
coredump_backends on qemu_cortex_m3, which has no data cache, also
with the flush forced to fail, and on nrf54h20dk/nrf54h20/cpuapp.
On nrf54h20dk/nrf54h20/cpuapp, a dump written before a pin reset was
found after it 5/5 times, and a dump erased before a pin reset stayed
erased 5/5 times. Without this change, the dump was lost 5/5 times
and an erased dump came back 3/3 times.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Victor Brzeski <vbrzeski@gmail.com>
Utilize a code spell-checking tool to scan for and correct spelling errors
in all files within:
- `subsys/debug`
Assisted-by: Claude:claude-sonnet-5-5 codespell
Signed-off-by: Pisit Sawangvonganan <pisit@ndrsolution.com>
Hopefully a script that helps the zassert migration for various subsystems.
1. ./scripts/coccicheck --mode=patch \
--cocci=subsys/debug/zassert/zassert.cocci ${path} > patch.diff
2. git apply patch.diff
3. Pray to what ever deity you feel like and verify
Known limitations:
* It will not be able to add a ZASSERT_MODULE(...) to the TUs it modifies,
so you will have to do that manually.
* It will not know the distinction between a .c and .h file so it will not
add the ZASSERT_MODULE(...) neccesary for the .h files. You will have to
do that manually as well.
Signed-off-by: Måns Ansgariusson <mansgariusson@gmail.com>
Replace scripts/kconfig/hardened.csv with a distributed YAML database.
The CSV format could not carry any explanation for its recommendations,
had no validation (a malformed line was silently dropped), no notion of
profiles, no ownership story, and no way to extend it out of tree.
The database now lives where the code lives: the central
scripts/kconfig/hardening.yaml defines the hardening profiles (plus
rules for top-level Kconfig symbols), and per-subsystem hardening.yaml
fragments next to the relevant Kconfig files carry the rules, so each
rule is reviewed by the maintainers of the code it hardens. Every rule
has a required rationale and optional references, supports exact-value
and integer min/max recommendations (STACK_POINTER_RANDOM is now
'>=100' instead of '==100'), and belongs to a profile: 'base' (memory
protection and inherently insecure features) or 'strict' (extends base
with debug/observability feature removal). The default profile is
'strict', matching the rule set the CSV checked.
hardenconfig is restructured around a serializable HardeningReport
model so results can be consumed programmatically, and gains:
- a Rationale column in the report
- profile selection:
west build -t hardenconfig -- -DHARDENCONFIG_PROFILE=base
- HARDENCONFIG_SHOW_ALL to also list PASS/NA results
- HARDENCONFIG_STRICT to exit non-zero on failures, for CI use
- HARDENCONFIG_JSON to write machine-readable results, including which
database file each rule came from
- HARDENCONFIG_EXTRA_SOURCES to layer out-of-tree database files that
may add profiles/rules and override in-tree ones
The EXPERIMENTAL/DEPRECATED/NOT_SECURE marker symbol detection is
preserved unchanged.
Three CSV entries are intentionally not carried over because they were
redundant: BT_CONN_DISABLE_SECURITY and BT_OOB_DATA_FIXED can only be
enabled together with BT_TESTING, and TIMER_RANDOM_GENERATOR together
with TEST_RANDOM_GENERATOR, all of which the database already
recommends disabling for the same profiles.
Behavioral fix: the CSV's DEBUG_COREDUMP line used '=' instead of ','
and was silently ignored, so CONFIG_DEBUG_COREDUMP was never actually
checked; it now is.
Also add tabulate to requirements-base.txt: hardenconfig has always
imported it, but it was only pulled in via other requirements files.
Assisted-by: Claude:fable-5
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
A fatal error raised while a dump is in progress, such as an assertion
in the backend, calls coredump() again and re-enters the backend in the
middle of the dump. On Cortex-M this ends in a lockup. Skip the dump in
that case, and let only one CPU dump at a time.
Assisted-by: Claude:opus-5.5
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
GCC warns that bind_storage may be used uninitialized, as its address
is taken before the memset(), which breaks coverage builds using
-Werror. Zero-initialize it at declaration instead.
Assisted-by: Claude:opus-5.5
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
When logging offsets in the in-memory coredump backend, place explicit
casts to long so that the existing %lu formatting directives work.
Signed-off-by: Keith Packard <keithp@keithp.com>
Introduce ZASSERT, a self-contained assertion facility configured per
source file through a named module rather than the single global
CONFIG_ASSERT switch.
A file selects its module with ZASSERT_MODULE(); the level is resolved
from CONFIG_ASSERT_MODULE_<MODULE>_LEVEL and may be overridden per file.
Modules are defined with the Kconfig.template.assert template, which takes
module/module-str inputs following the logging template convention.
The four levels are:
- Off (compiled out)
- Terse (check only)
- On (check + location only)
- Verbose (Check, location, condition and message)
Since the level is known at compile time, disabled assertions are folded
away by the compiler, and below Verbose the optional message and its
arguments are as well.
zassert provides a set of __weak overridable hooks:
- zassert_fail() - called when an assertion fails
- zassert_vprint() - called to print the assertion failure message
- zassert_post_action() - the terminal action after an assertion failure
CONFIG_ASSERT remains the master switch. The assert Kconfig moves from
subsys/debug to lib/os/zassert, the legacy CONFIG_ASSERT_* symbols are kept
but deprecated (mapped onto the DEFAULT module), and lib/os/assert.c is
removed. The __ASSERT() family is preserved as a thin compatibility shim
over the DEFAULT module, so existing call sites keep working unchanged.
Signed-off-by: Måns Ansgariusson <mansgariusson@gmail.com>
CONFIG_ASSERT_CUSTOM_HEADER let an application inject a
"zephyr_custom_assert.h" at the end of <zephyr/sys/__assert.h> to extend
the assert macros at the preprocessor level. It has always been
experimental and explicitly warned that the internal assert API may change,
so it is removed without a deprecation period, per the experimental API
policy.
Applications that need to customize assertion handling should override the
weak assert hooks instead.
Remove the Kconfig option, the __assert.h include hook and the
assert_custom_header test.
Signed-off-by: Måns Ansgariusson <mansgariusson@gmail.com>
Nothing in asserts infra is related to spin validation, spin validation
should not be automatically enable when someone wants to enable assert
and suffer the cost in flash and performance.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
TriCore does not store the stack pointer at a fixed offset in
the thread struct. Mark as unimplemented to suppress the build
warning promoted to error by -Werror.
Signed-off-by: Parthiban Nallathambi <parthiban@linumiz.com>
Add a coredump backend for the AMD ACP DSP that stores the Zephyr
coredump together with a SOF compatible DSP "oops" record in the ACP
exception buffer. The backend writes the panic code where the SOF host
driver expects it and raises a DSP-to-host interrupt so the host can
collect the dump.
Enable ARCH_SUPPORTS_COREDUMP for the acp_7_x SoC and wire the new
backend into the coredump core and build.
Signed-off-by: DineshKumar Kalva <DineshKumar.Kalva@amd.com>
Add THREAD_INFO_OFFSET_T_STACK_PTR for Hexagon using switch_handle,
which holds the saved stack pointer for non-current threads. Required
by GDB scripts and debugger plugins that walk the thread list.
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
Header signature checks used &&, so a dump was rejected only when both
ID bytes were wrong. Partial matches such as "C\0" or "\0D" were treated
as valid and could make verify/find/print succeed on garbage data.
Require both 'C' and 'D' in process_stored_dump() and get_stored_dump().
Signed-off-by: Yuan Bian <bianyuan@kylinos.cn>
A thread actively running on another CPU at panic time was previously
invisible to real debugging: coredump only captured the panicking CPU's
exception frame, so every other thread's registers came from its
k_thread.callee_saved struct -- correct for genuinely sleeping threads,
but stale (reflecting whenever it last voluntarily context switched) for
one that's actually running elsewhere right now.
Add CONFIG_DEBUG_COREDUMP_SMP_FREEZE_CPUS (default y where the arch sets
ARCH_SUPPORTS_COREDUMP_SMP_FREEZE, i.e. arm64 Cortex-A SMP). On panic,
coredump() freezes every other online CPU before dumping and thaws them
after the memory-region walk, and emits each frozen CPU's live registers
as a new coredump section (COREDUMP_CPU_SNAPSHOT_HDR_ID, tagged with CPU
index and thread pointer, reusing the arch-info block register layout).
The panicking CPU (never frozen, since freeze only targets other CPUs)
emits a zero-payload marker recording only which thread was panicking
there, which the host side uses to identify it unambiguously.
arm64 implementation (arch/arm64/core/smp.c, coredump.c): send a new SGI
to every other online CPU. Each handler captures its exact live state --
x0-x18/lr/spsr/elr via the arch_esf that _isr_wrapper() stashes at a
fixed, nesting-independent slot on its IRQ stack, plus x19-x29 via inline
asm (valid per AAPCS64) -- then spins holding whatever it held before
being frozen, untouched, until the dump finishes, and resumes via the
standard exception-return path exactly where it was interrupted. This
matters because a panic here can be recoverable (this tree's own
coredump_threads test doesn't halt/reboot after dumping).
The SGI uses a deliberately low priority (SGI_COREDUMP_FREEZE_PRIO), not
IRQ_DEFAULT_PRIORITY: a frozen CPU never returns from its handler so
_isr_wrapper() never EOIs, and per GIC priority rules only a strictly
higher-priority interrupt can preempt a still-active one. At the default
priority a frozen CPU could not service same-priority peripheral
interrupts (confirmed on hardware as Ethernet TX-done starvation during
the UDP backend); the lowest usable priority lets everything else keep
making progress while a CPU waits.
The freeze/thaw handshake uses two separate per-CPU signals: freeze_state
(IDLE/REQUESTED/CAPTURED) and a dedicated release_requested flag that
only thaw writes. Kept separate so a late-arriving CPU (whose SGI was
delayed past the freeze-side timeout) still sees a release signal instead
of stomping it with its own CAPTURED update and spinning forever; thaw
sets release_requested unconditionally for every other CPU. The handler
wait is also bounded by a 60-second wall-clock backstop (k_cycle_get_32(),
safe from any context) so no CPU is ever stuck indefinitely. A CPU that
never responds within the freeze-side timeout (never booted, or stuck
with IRQs masked) is skipped and never blocks the dump.
The host coredump log parser learns to parse the new snapshot section.
Signed-off-by: Appana Durga Kedareswara rao <appana.durga.kedareswara.rao@amd.com>
After writing the final aligned datum, write_sz becomes zero and the
code reads from the next aligned address even though no data remains.
This unnecessary read may access an invalid address.
Signed-off-by: Yuan Bian <bianyuan@kylinos.cn>
GDB RSP packets are framed as $<payload>#<CS_hi><CS_lo>. When the
payload exceeds the receive buffer, gdb_get_packet() NACKed and
returned without consuming the two checksum bytes still in the RX
stream. Later z_gdb_getchar() calls then read those leftover bytes
instead of the expected ACK or next packet start, desynchronizing the
session.
Drain and discard the checksum before sending '-' so the stream stays
aligned with GDB framing.
Signed-off-by: Yuan Bian <bianyuan@kylinos.cn>
Updated the coredump logging backend to ensure that LOG_PROCESS()
is not called before LOG_PANIC(). This change prevents buffered
messages from being delivered while backends are still in normal
mode, aligning the logging behavior with the intended panic
notification flow.
Signed-off-by: Dhruv Menon <dhruvmenon1104@gmail.com>
coredump_mem_window_backend_start() unconditionally force-seized debug
slot 1 for ADSP_DW_SLOT_TELEMETRY, even when telemetry_init() had
already been assigned a different slot by the dynamic debug slot
manager. This could leave two descriptors of type
ADSP_DW_SLOT_TELEMETRY around, with the host possibly reading the
stale one instead of the slot the coredump was actually written to.
Try adsp_dw_request_slot() first so the coredump reuses the slot
telemetry already owns, if any, and only fall back to forcibly
seizing slot 1 (then slot 0) when no telemetry slot exists yet.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
coredump_mem_window_backend_buffer_output() only rejected a write that
starts at or past the end of the slot; it never clamped buflen itself.
A chunk that pushes mem_wptr from just below the ADSP_DW_SLOT_SIZE - 4
limit to past it therefore overruns the current debug window slot and
spills into whatever slot is physically adjacent in memory.
With the static slot layout (CONFIG_INTEL_ADSP_DEBUG_SLOT_MANAGER=n)
this overrun landed in unused space past the last real slot, so it
went unnoticed. With the dynamic debug slot manager enabled, the
telemetry/coredump slot can end up placed right before another
consumer's slot (e.g. the mtrace log ring buffer), and the same
overrun corrupts that live slot instead.
Clamp buflen to the remaining space in the slot before copying so a
write can never cross into the next slot.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
subsys/debug/thread_info.c previously refused to build DEBUG_THREAD_INFO
at all on SMP: its K_CURR_THREAD offset is offsetof(struct _cpu, current)
applied to struct z_kernel, which only ever resolves to cpus[0].current,
so it #error'd out for CONFIG_MP_MAX_NUM_CPUS > 1 and DEBUG_THREAD_INFO
carried a "depends on !SMP".
Remove that restriction and append two new offset-table entries,
CPU_STRIDE (sizeof(struct _cpu)) and NUM_CPUS, so a consumer can compute
every CPU's current thread as cpus[i].current = K_CURR_THREAD +
i * CPU_STRIDE. The entries are append-only, so they don't change the
interpretation of any existing offset: a debugger plugin that doesn't
know about them keeps seeing cpus[0] only, exactly as before.
With DEBUG_THREAD_INFO now SMP-safe, the coredump THREADS-mode and
threads-metadata options select it unconditionally instead of falling
back to THREAD_MONITOR on SMP, so the offline GDB thread enumeration
path is available on both SMP and non-SMP targets.
Signed-off-by: Appana Durga Kedareswara rao <appana.durga.kedareswara.rao@amd.com>
The SMP thread-list walk in process_memory_region_list() held
z_thread_monitor_lock for the entire per-thread dump loop, including
each thread's dump_thread() call. For slow backends (e.g. the UDP
logging backend, which transmits every thread's stack over the
network) this can hold the lock for seconds.
If another CPU's thread exits naturally during that window,
k_thread_abort() -> halt_thread() -> z_thread_monitor_exit() needs
the same lock and spins until the entire dump completes. Confirmed on
versalnet_apu_se9/amd_versalnet_apu/smp via a live backtrace showing
exactly that spin (arm_gic_irq_is_pending <- arch_spin_relax <-
k_spin_lock <- halt_thread <- z_impl_k_thread_abort) while
CONFIG_DEBUG_COREDUMP_BACKEND_LOGGING_UDP was mid-dump.
Snapshot the thread pointers into a small bounded array while holding
the lock, then release it before calling dump_thread() for each
snapshotted thread, so slow per-thread I/O never runs with the lock
held. Confirmed on hardware: hs6_smp_udp_backend now completes and
captures all 165 UDP datagrams cleanly, with no regression on the
non-SMP path.
The snapshot array's size is exposed as
CONFIG_DEBUG_COREDUMP_THREAD_SNAPSHOT_MAX (default 64) instead of a
hardcoded cap, so a system with more monitored threads can capture all
of them; systems that exceed it dump the first N rather than growing
fatal-path stack unbounded. A mid-dump truncation diagnostic is
intentionally not emitted, as it would corrupt the backend's parseable
coredump byte stream.
Signed-off-by: Appana Durga Kedareswara rao <appana.durga.kedareswara.rao@amd.com>
gdb_bin2hex() rejected hexlen when (hexlen + 1) < buflen * 2, which
admitted hexlen == 2*buflen - 1. The loop writes indices 0..2*buflen-1,
so a one-byte write past the destination occurred for odd-length inputs.
Tighten the check to hexlen < buflen * 2.
Assisted-by: Claude:claude-sonnet-4-6
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Remove the !SMP dependency from DEBUG_COREDUMP_MEMORY_DUMP_THREADS and
DEBUG_COREDUMP_THREADS_METADATA so THREADS mode is available on SMP
platforms.
On non-SMP builds DEBUG_THREAD_INFO is still selected, preserving
_kernel_thread_info_offsets for offline GDB thread enumeration. On SMP
THREAD_MONITOR is selected instead: DEBUG_THREAD_INFO is not SMP-safe as
thread_info.c exports K_CURR_THREAD reflecting only cpus[0].current, which
misleads live RTOS debugger plugins on multi-core systems. Document this
limitation in the DEBUG_THREAD_INFO Kconfig help text.
Hold z_thread_monitor_lock while walking _kernel.threads so the list is
stable against concurrent k_thread_create/exit on other CPUs. On
uniprocessor IRQs are already locked, making this a no-op.
Extend the ISR stack dump to all CONFIG_MP_MAX_NUM_CPUS cores instead of
only cpus[0], since a crash can occur in an interrupt handler on any core.
Signed-off-by: Appana Durga Kedareswara rao <appana.durga.kedareswara.rao@amd.com>
The idle-hook based CPU load module lived under subsys/debug, required
CONFIG_TRACING, and exposed its API through <zephyr/debug/cpu_load.h>.
It does not conceptually belong to the debug subsystem, and its only
dependency on tracing was the idle notification hooks, now available
through CONFIG_SYS_IDLE_HOOKS.
Move the module to lib/os/cpu_load with its own CMakeLists and Kconfig,
relocate the public header to <zephyr/sys/cpu_load.h>, and select
SYS_IDLE_HOOKS instead of TRACING. Update all includers (the tracing
backends, samples and tests) to the new header path.
CONFIG_CPU_LOAD now builds and runs without the tracing subsystem.
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
uart drivers, that init in POST_KERNEL and
not in PRE_KERNEL_1 can't support
CONFIG_EARLY_CONSOLE, add a Kconfig for it.
Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>
the boot banner is printed at the end of
the init process with
``SYS_INIT(boot_banner, APPLICATION, 0);``
we don't need the early console for it.
When CONFIG_EARLY_CONSOLE is enabled,
the console will init with PRE_KERNEL_1, otherwise
with POST_KERNEL. Both are before APPLICATION.
For compatibility `EARLY_CONSOLE` will now be enabled by default,
as it was selected by the boot banner before, that is also
enabled by default.
Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>
The fast nibble-copy path in the MIPI STP decoder assumes unaligned
multiword accesses are safe on Cortex-M.
With clang on mps2/an385 this can still generate unaligned accesses in
the optimized path, causing a UsageFault in debug.mipi_stp_decoder.
Disable the fast path for clang (and when unaligned trapping is
enabled), falling back to the existing byte-wise safe path.
Assisted-by: GitHub Copilot:GPT-5.3-Codex
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Extend callback to return a bool which indicates if decoded data is
valid. It may be valid from STP protocol perspective but decoded data
may be unexpected which indicates that data stream is corrupted. If
callback indicates invalid data decoder changes state to out of sync
and starts searching for ASYNC.
Adapted test and debug_nrf_etr module which is using the decoder with
stream from the ETR buffer.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
Add CONFIG_DEBUG_COREDUMP_BACKEND_LOGGING_UDP, a new coredump backend
that sends the raw coredump byte stream over UDP while optionally
mirroring the standard #CD: hex lines through the logging subsystem.
Each buffer segment is transmitted as a self-describing UDP datagram
with a 16-byte header: 4-byte magic "ZCDU", 32-bit byte offset in the
reassembled stream, 16-bit payload length, 16-bit flags (bit 0 = END),
and a 32-bit sequence number for diagnostics. The host-side
coredump_udp_receiver.py reassembles datagrams by offset and writes a
raw .bin file for coredump_gdbserver.py.
Peer destination is CONFIG_DEBUG_COREDUMP_LOGGING_UDP_HOST, a string
parsed by net_ipaddr_parse() supporting both IPv4 (192.0.2.1:17777)
and IPv6 ([2001:db8::1]:17777). Port 17777 is used when omitted.
UART mirroring can be suppressed with
CONFIG_DEBUG_COREDUMP_LOGGING_UDP_MIRROR_TO_LOG=n; the logging
subsystem is not selected when mirroring is disabled.
Also adds the generic weak fallback for arch_coredump_fatal_irq_unlock/
lock (delegates to arch_irq_unlock/lock) under
CONFIG_DEBUG_COREDUMP_FATAL_UNLOCK_IRQS. Architectures with independent
IRQ masking must override these — see arch/arm64/core/coredump_fatal_irq.c.
Signed-off-by: Appana Durga Kedareswara rao <appana.durga.kedareswara.rao@amd.com>
Adding CALLGRAPH_INFO to allow to export compilation unit level callgraph
files from GCC. Complementing the existing STACK_USAGE options to follow
the initial intention to use both options together for stack use analysis.
Signed-off-by: Paul Würtz <paulwuertz@posteo.de>
Add cpu_load support for Xtensa.
Fix an issue in Xtensa tracing where sys_trace_idle_exit
was not called, causing idle time to be collected incorrectly.
Signed-off-by: Frank Li <lgl88911@163.com>
This performs a check of target code using it as index to
retrieve target string via the target code string array.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
If we are receiving more bytes than the buffer size, we return
early in gdb_get_packet(). There is no need to go through all
the checksum calculation as it is going to be wrong anyway.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The cpu_load measurement window (cyc_start, ticks_idle) is only updated
inside cpu_load_get(reset=true), which the periodic timer calls on every
firing. When the periodic timer is started for the first time at
SYS_INIT, or later restarted via cpu_load_log_control(true), the window
inherits whatever stale values cyc_start and ticks_idle happened to
have. The first periodic firing after a (re)start therefore measures
load over an arbitrary, ill-defined interval and may report any value.
For the SYS_INIT path this just means the very first logged load reads
as ~100% (cyc_start is implicitly 0 while ticks_idle has only counted
idle since cpu_load_init). More importantly, for cpu_load_log_control
it makes the first measurement after re-enabling the timer depend on
whatever the caller happened to do between the previous stop and the
new start, defeating the point of stopping/restarting in the first
place.
Reset the window with cpu_load_get(true) before each k_timer_start so
the first firing measures a well-defined interval that begins exactly
at the (re)start point.
Update the callback tests to call cpu_load_log_control(true) at entry
and cpu_load_log_control(false) at exit, instead of free-riding on the
SYS_INIT-started timer. Combined with the window reset above, each
test now starts measuring from a known baseline, making
test_callback_load_low deterministic regardless of how busy the CPU was
at the end of the preceding test.
In test_periodic_report, add log_flush() before each log_cnt assertion.
log_cnt is incremented asynchronously by the deferred-mode log thread
when it dispatches messages to the dummy backend. Without flushing,
the assertion can read log_cnt while the 3 cpu_load LOG_INFs queued
during k_msleep(150) are still pending in the queue (the log thread
wakes only when the queue reaches 10 messages or after 1000 ms). The
test passes by accident on platforms where the log thread happens to
have been woken by other traffic during the test window, and fails
deterministically elsewhere. log_flush() blocks until the queue is
drained, so log_cnt becomes a deterministic count regardless of host
or scheduler timing.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Modify stack sizes to start at the fixed size of 4 and % with a
fixed size of 3. Percentages should never be more than 3 digits
in this case, and the majority of stack sizes should never exceed
9999, and if they do, then it just pads them.
The purpose of this is to just a slightly cleaner table where each
row has the same width.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
New option CONFIG_THREAD_ANALYZER_PRINT_THREAD_PRIORITY that includes
each thread's priority to the print output of thread analyzer.
Signed-off-by: Jonathan Karlsson <karlsson_jonathan@hotmail.com>
When optimized for speed it was possible that compiler for ARM Cortex-M
used double word read for code that was reading two words from an array.
However, it was possible that this array was not word-aligned and
double word access was resulting in a bus fault. Refactored the function
to ensure that only word access is used (word access on Cortex-M4 and
later supports unaligned access).
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
Extends SPIN_VALIDATE feature to support up to 8 CPUs on
64-bit systems while maintaining backward compatibility with 32-bit
systems (which still support up to 4 CPUs).
Many modern SoCs have more than 4 CPU cores, yet the SPIN_VALIDATE
feature was only available for systems with MP_MAX_NUM_CPUS <= 4.
This limitation becomes increasingly relevant as multi-core designs
with 6-8 cores become common in both embedded and server applications.
The implementation leverages pointer alignment guarantees:
- On 32-bit systems: pointers are 4-byte aligned → 2 free bits →
up to 4 CPUs
- On 64-bit systems: pointers are 8-byte aligned → 3 free bits →
up to 8 CPUs
Signed-off-by: Li Jie <lijie.1996@picoheart.com>
process_stored_dump() uses data_read() without checking the return value.
The function then uses a potentially uninitialized hdr variable.
Check data_read() return value and return the value if negative.
Signed-off-by: Jeppe Odgaard <jeppe.odgaard@prevas.dk>
In certain configurations there could be a warning due to potential
use of uninitialized variable. Add initialization.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
In OpenRISC 1000, the stack pointer is stored in the r1 register. This
patch stores the offset of this value within in the thread structure into
the thread info offsets.
Signed-off-by: Joel Holdsworth <jholdsworth@nvidia.com>
The espressif toolchain variant (ZEPHYR_TOOLCHAIN_VARIANT=espressif)
has not been used for years. Espressif targets are now built using the
Zephyr SDK, which bundles the required Xtensa and RISC-V toolchains.
Remove the cmake/toolchain/espressif/ directory containing generic.cmake,
target.cmake, and Kconfig files that implemented this variant. Also
clean up references in the coredump xtensa gdb stubs, removing the
ESPRESSIF toolchain enum value and related handling code.
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
Replaces usage of these deprecated macros with ones that support
fixed and mapped partition compatibles. Also includes an update to
hal_espressif which also (rightly or wrongly) has zephyr specific
code in it
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Fix error-checking bug in Zephyr `coredump_shell.c` for
`coredump_cmd(COREDUMP_CMD_COPY_STORED_DUMP, ...)`. The function
returns the number of bytes copied (≥ 0) on success and a negative
errno on failure, but the existing checks used `ret != 0` which
incorrectly treated a successful non-zero byte count as an error.
This bug prevented the coredump printing shell commands from working.
signed-off-by: Glenn Andrews <andrewsglenn@meta.com>
`THREAD_RUNTIME_STATS` is not a requirement for the thread analyzer to
operate, merely useful. Switch the control to `configdefault` to leave
it enabled by default, while allowing both applications to disable the
option with `CONFIG_THREAD_RUNTIME_STATS=n` and for alternate defaults
to be specified elsewhere.
Signed-off-by: Jordan Yates <jordan@embeint.com>
Add calls to sys_trace_idle_exit before leaving idle state
to track CPU load.
Extend CPU_LOAD to CPU_AARCH32_CORTEX_R and CPU_AARCH32_CORTEX_A, thus
we can support CPU_LOAD for all CPU_CORTEX.
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
