Merge branch 'bugfix/heap_tracing_build_issue_for_c3' into 'master'

heap: fix build issue with HEAP_TRACING config for C3

See merge request espressif/esp-idf!13948

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

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

docs/en/api-reference/system/heap_debug.rst

@@ -213,7 +213,11 @@ An example::
       ...
   }
 
-The output from the heap trace will look something like this::
+The output from the heap trace will look something like this:
+
+.. only:: CONFIG_IDF_TARGET_ARCH_XTENSA
+
+    ::
 
         2 allocations trace (100 entry buffer)
         32 bytes (@ 0x3ffaf214) allocated CPU 0 ccount 0x2e9b7384 caller 0x400d276d:0x400d27c1
@@ -229,18 +233,31 @@ The output from the heap trace will look something like this::
         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 </api-guides/tools/idf-monitor>` to automatically decode PC addresses to their source files & line number.)
 
 The first line indicates how many allocation entries are in the buffer, compared to its total size.
 
 In ``HEAP_TRACE_LEAKS`` mode, for each traced memory allocation which has not already been freed a line is printed with:
 
+.. list::
+
     - ``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.
+    :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.
 

tools/test_apps/system/build_test/sdkconfig.ci.heap_tracing

@@ -0,0 +1 @@
+CONFIG_HEAP_TRACING_STANDALONE=y