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,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:
+
+.. only:: CONFIG_IDF_TARGET_ARCH_XTENSA
+
+    ::
+
+        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
 
-  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
+        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
 
-  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
 
-  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
 
-  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.)
 
@@ -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::
+
+    - ``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.
+    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.
 

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

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