In order to bring consistency in-tree, migrate all tests to the new
prefix <zephyr/...>. Note that the conversion has been scripted, refer
to #45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Move to CMake 3.20.0.
At the Toolchain WG it was decided to move to CMake 3.20.0.
The main reason for increasing CMake version is better toolchain
support.
Better toolchain support is added in the following CMake versions:
- armclang, CMake 3.15
- Intel oneAPI, CMake 3.20
- IAR, CMake 3.15 and 3.20
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
The biggest required padding is equal to `align - chunk_header_bytes`
and not `align - 1` given that the header already contributes to the
padding.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
The code that made aligned_alloc work with the 4-byte heap headers was
requesting a block of the correctly padded size, and correctly
aligning the output buffer within that memory, but it was using the
UNALIGNED chunk size for the buffer as the final size of the block
with splitting off the unused suffix. So the final chunk in the
buffer was could be incorrectly returned to the heap and reused,
leading to overlap.
Compute the chunk size of the output buffer based on the
already-aligned output pointer instead.
Initial investigation and fix from Andy Ross <andrew.j.ross@intel.com>.
I reworked his fix, created a test case, and stolen his commit log.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
After commit 8a6b02b5bf ("lib/os/heap: some code simplification in
sys_heap_aligned_alloc()") it is no longer required to have a "big"
heap for aligned allocations to work on 32-bit targets. While the
natural alignment for returned memory has an offset of 4 within a chunk
unit due to the smaller header size, returning to a chunkid from a
memory pointer with an offset of 8 will fall back onto the proper chunk
number once the 4 is substracted and then divided by 8.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Many issues:
- heapmem[] is of type uint64_t meaning that it contains HEAP_SZ * 16
bytes but the heap is initialized with only 1/16 of that, making
this test's memory footprint way too large.
- The test to ensure the heap is empty uses an allocation size of
(heap_end - heap_start - 8) which is wrong as heap_end and heap_start
are uint64_t pointer types and therefore their difference will be 8x
smaller than intended. Furthermore, the 8 here is unnessary as the
chunk header size is already included in the location of heap_start.
- The heap start address misalignment bare no purpose as the misaligned
start of the free heap is already controlled by the variable prefix
allocation size.
- Alignment and sizes should rather be expressed in terms of size_t
rather than uintptr_t.
Fix those issues, and add a few more test angles:
- Make the prefix allocation itterate across the entire alignment range
to exercize all possible misalignments.
- Vary the aligned allocation size to better exercize the pre-alignment
allocation and suffix handling.
- Double the aligned allocation to add more variability in the heap
structure.
- Test the testing of emptiness by making sure that no more allocations
are possible when we think we allocated it all.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Test of the sys_heap_aligned_alloc() API. This is separate from the
existing heap test because aligned_alloc() requires a kconfig to
enable it that can change the heap block header format and will impact
code coverage of the "small" block variant.
It's a fairly simple whitebox test that instantiates a heap and then
enumerates all possible alignments within it, with and without
pre-allocated data, to verify that the resulting memory is correctly
aligned and the heap stays consistent.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Gerard Marull-Paretas