diff --git a/components/heap/Kconfig b/components/heap/Kconfig index 34c044fc69..5b9dc56189 100644 --- a/components/heap/Kconfig +++ b/components/heap/Kconfig @@ -45,6 +45,8 @@ menu "Heap memory debugging" config HEAP_TRACING_STACK_DEPTH int "Heap tracing stack depth" + range 0 0 if IDF_TARGET_ARCH_RISCV # Disabled for RISC-V due to `__builtin_return_address` limitation + default 0 if IDF_TARGET_ARCH_RISCV range 0 10 default 2 depends on HEAP_TRACING diff --git a/components/heap/include/heap_trace.inc b/components/heap/include/heap_trace.inc index e6a039530b..6f78928549 100644 --- a/components/heap/include/heap_trace.inc +++ b/components/heap/include/heap_trace.inc @@ -19,7 +19,7 @@ /* Encode the CPU ID in the LSB of the ccount value */ inline static uint32_t get_ccount(void) { - uint32_t ccount = xthal_get_ccount() & ~3; + uint32_t ccount = cpu_hal_get_cycle_count() & ~3; #ifndef CONFIG_FREERTOS_UNICORE ccount |= xPortGetCoreID(); #endif diff --git a/docs/en/api-reference/system/heap_debug.rst b/docs/en/api-reference/system/heap_debug.rst index 12350ed20d..f272ec825d 100644 --- a/docs/en/api-reference/system/heap_debug.rst +++ b/docs/en/api-reference/system/heap_debug.rst @@ -213,21 +213,35 @@ An example:: ... } -The output from the heap trace will look something like this:: +The output from the heap trace will look something like this: - 2 allocations trace (100 entry buffer) - 32 bytes (@ 0x3ffaf214) allocated CPU 0 ccount 0x2e9b7384 caller 0x400d276d:0x400d27c1 - 0x400d276d: leak_some_memory at /path/to/idf/examples/get-started/blink/main/./blink.c:27 +.. only:: CONFIG_IDF_TARGET_ARCH_XTENSA - 0x400d27c1: blink_task at /path/to/idf/examples/get-started/blink/main/./blink.c:52 + :: - 8 bytes (@ 0x3ffaf804) allocated CPU 0 ccount 0x2e9b79c0 caller 0x400d2776:0x400d27c1 - 0x400d2776: leak_some_memory at /path/to/idf/examples/get-started/blink/main/./blink.c:29 + 2 allocations trace (100 entry buffer) + 32 bytes (@ 0x3ffaf214) allocated CPU 0 ccount 0x2e9b7384 caller 0x400d276d:0x400d27c1 + 0x400d276d: leak_some_memory at /path/to/idf/examples/get-started/blink/main/./blink.c:27 - 0x400d27c1: blink_task at /path/to/idf/examples/get-started/blink/main/./blink.c:52 + 0x400d27c1: blink_task at /path/to/idf/examples/get-started/blink/main/./blink.c:52 - 40 bytes 'leaked' in trace (2 allocations) - total allocations 2 total frees 0 + 8 bytes (@ 0x3ffaf804) allocated CPU 0 ccount 0x2e9b79c0 caller 0x400d2776:0x400d27c1 + 0x400d2776: leak_some_memory at /path/to/idf/examples/get-started/blink/main/./blink.c:29 + + 0x400d27c1: blink_task at /path/to/idf/examples/get-started/blink/main/./blink.c:52 + + 40 bytes 'leaked' in trace (2 allocations) + total allocations 2 total frees 0 + +.. only:: CONFIG_IDF_TARGET_ARCH_RISCV + + :: + + 2 allocations trace (100 entry buffer) + 32 bytes (@ 0x3ffaf214) allocated CPU 0 ccount 0x2e9b7384 caller + 8 bytes (@ 0x3ffaf804) allocated CPU 0 ccount 0x2e9b79c0 caller + 40 bytes 'leaked' in trace (2 allocations) + total allocations 2 total frees 0 (Above example output is using :doc:`IDF Monitor ` to automatically decode PC addresses to their source files & line number.) @@ -235,14 +249,17 @@ The first line indicates how many allocation entries are in the buffer, compared In ``HEAP_TRACE_LEAKS`` mode, for each traced memory allocation which has not already been freed a line is printed with: -- ``XX bytes`` is number of bytes allocated -- ``@ 0x...`` is the heap address returned from malloc/calloc. -- ``CPU x`` is the CPU (0 or 1) running when the allocation was made. -- ``ccount 0x...`` is the CCOUNT (CPU cycle count) register value when the allocation was mode. Is different for CPU 0 vs CPU 1. -- ``caller 0x...`` gives the call stack of the call to malloc()/free(), as a list of PC addresses. - These can be decoded to source files and line numbers, as shown above. +.. list:: -The depth of the call stack recorded for each trace entry can be configured in the project configuration menu, under ``Heap Memory Debugging`` -> ``Enable heap tracing`` -> ``Heap tracing stack depth``. Up to 10 stack frames can be recorded for each allocation (the default is 2). Each additional stack frame increases the memory usage of each ``heap_trace_record_t`` record by eight bytes. + - ``XX bytes`` is number of bytes allocated + - ``@ 0x...`` is the heap address returned from malloc/calloc. + - ``CPU x`` is the CPU (0 or 1) running when the allocation was made. + - ``ccount 0x...`` is the CCOUNT (CPU cycle count) register value when the allocation was mode. Is different for CPU 0 vs CPU 1. + :CONFIG_IDF_TARGET_ARCH_XTENSA: - ``caller 0x...`` gives the call stack of the call to malloc()/free(), as a list of PC addresses. These can be decoded to source files and line numbers, as shown above. + +.. only:: not CONFIG_IDF_TARGET_ARCH_RISCV + + The depth of the call stack recorded for each trace entry can be configured in the project configuration menu, under ``Heap Memory Debugging`` -> ``Enable heap tracing`` -> ``Heap tracing stack depth``. Up to 10 stack frames can be recorded for each allocation (the default is 2). Each additional stack frame increases the memory usage of each ``heap_trace_record_t`` record by eight bytes. Finally, the total number of 'leaked' bytes (bytes allocated but not freed while trace was running) is printed, and the total number of allocations this represents. diff --git a/tools/test_apps/system/build_test/sdkconfig.ci.heap_tracing b/tools/test_apps/system/build_test/sdkconfig.ci.heap_tracing new file mode 100644 index 0000000000..7ae900accf --- /dev/null +++ b/tools/test_apps/system/build_test/sdkconfig.ci.heap_tracing @@ -0,0 +1 @@ +CONFIG_HEAP_TRACING_STANDALONE=y