From dd73ba960144e1d7344ecc970ac8df5b04a307e2 Mon Sep 17 00:00:00 2001 From: Mahavir Jain Date: Fri, 11 Jun 2021 13:08:11 +0530 Subject: [PATCH 1/3] heap: use hal specific API to get cpu cycles count This fixes compilation issue of heap tracing feature for RISC-V architecture. --- components/heap/Kconfig | 2 ++ components/heap/include/heap_trace.inc | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) 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 From 1c0fb793b4e8926b67a64778544eefc2b6fb0105 Mon Sep 17 00:00:00 2001 From: Mahavir Jain Date: Fri, 11 Jun 2021 13:10:59 +0530 Subject: [PATCH 2/3] test_apps: add HEAP_TRACING configuration to build tests --- tools/test_apps/system/build_test/sdkconfig.ci.heap_tracing | 1 + 1 file changed, 1 insertion(+) create mode 100644 tools/test_apps/system/build_test/sdkconfig.ci.heap_tracing 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 From 46d04231e665c6f050b5bcecac898e15005a584c Mon Sep 17 00:00:00 2001 From: Mahavir Jain Date: Mon, 21 Jun 2021 10:28:17 +0530 Subject: [PATCH 3/3] docs/en: update heap debugging guide for tracing on RISC-V architecture --- docs/en/api-reference/system/heap_debug.rst | 51 ++++++++++++++------- 1 file changed, 34 insertions(+), 17 deletions(-) diff --git a/docs/en/api-reference/system/heap_debug.rst b/docs/en/api-reference/system/heap_debug.rst index fa4171405f..22e597e5bb 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.