- Remove the size limit for the hash_map array from the CONFIG_HEAP_TRACE_HASH_MAP_SIZE
- Add test case for heap tracing using hashmap
- Update heap_debug.rst to document the newly added configurations in the heap component
Closes https://github.com/espressif/esp-idf/issues/11172
Add test configuration to run all tests with heap component in the flash.
Add reference to this new configuration in performance section of the documentation.
- Fix "test get allocated size"
- Add tests for the free / alloc hooks
- Call alloc function hook on malloc/realloc/calloc base functions
- Add caps parameter to the allocation hook function
After heap_idf.c has been added (where the FreeRTOS heap is a subset of the
ESP-IDF heap), xPortGetFreeHeapSize() was updated to only returns the free
size of the FreeRTOS heap and not the entire ESP-IDF heap.
This commit replaces calls of xPortGetFreeHeapSize() with
esp_get_free_heap_size() in places outside of FreeRTOS.
- Call TAILQ_INSERT_TAIL in linked_list_setup to add unused records from the tail of the list
- Fix test "heap trace leak check" to expect that after a free, the record is zeroed instead of checking that
the whole list of records is moved by one index in the array.
- Use esp_rom_printf() under lock instead of printf() since it does not rely on interrupts.
When light (or comprehensive) poisoning is enabled, the size requested by the user for allocation
is extended by a few bytes to store the canary header and footer. heap_caps_get_allocated_size() should
return the original size asked by the user (without the additional canary bytes).
test_malloc.c extended with a new test assuring that heap_caps_get_allocated_size() returns the proper size
regardless of the degree of poisoning.
If memory protection is enabled on esp32c3 and esp32s3, we don't want to the heap component to see
the startup stack memory as D/IRAM but as DRAM only. Introduce a new type to make this possible in
the same fashion the regular D/IRAM regions are handled.
Check that when trying to allocate in IRAM with the system memory protection enabled,
null pointer is returned, or that an address in IRAM is returned if the memory protection
is disabled.
when CONFIG_ESP_SYSTEM_PMP_IDRAM_SPLIT is not set, the PMP rule for esp32c2 shoud allow write access.
Fix esp_cpu_configure_region_protection() in cpu.c accordingly.
Note: the checks for the tests marked as [test-dump] are done in the pytest function
test_heap_trace_dump() since they are relying on the content of the heap_trace_dump_caps()
output.
When stack check is enabled, certain functions (sometimes placed in RAM)
are being decorated with stack guards and a call to __stask_chk_fail() in
case ofr stack corruption. For this reason, __stack_chk_fail() must be
placed in RAM too.
Add stack check config in heap tests on all targets to find eventual flash to RAM
calls due to stack checks when running callgraph_check.py
On xtensa architecture, the call to __assert_func uses a reference to __func__ that can
sometimes be placed in flash. Since the __asert_func can be called from functions in IRAM
the check_callgraph script can report an error when checking for invalid calls from IRAM
to flash sections. However, the __asert_func prevents this scenario at runtime so the
check_callgraph script reports a 'flas positive' situation. For this reasson, all references
to __func__$x found prior to a call to __assert_func are droped in the parsing of the rtl files.
this commits:
- adds build-time test to check that no call to flash regions are done from IRAM functions
- resolves problems related to IRAM function using content in flash memory
- update heap_caps_alloc_failed to use a default function name in DRAM
when necessary instead of creating a function name variable in DRAM for
each call of heap_caps_alloc_failed. This allows to save some extra bytes
in RAM.
- update the target and host tests to consider the new TLSF api and the metadata size
only when the target is not using the rom implementation of the TLSF
Previously, condition_4 was making impossible the valid scenario
start > heap_start && end == heap_end.
Now, the end == heap_end and start == heap_start case is handled
separately allowing the case start > heap_start && ned == heap_end
to be considered a valid scenario
