Amend the filtering so that the normal mem_map (with exec) test
is not going to run on Intel Audio DSP SoCs.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This needs special treatment because the TEST_MEM_MAP section
is placed at the end. Since there is code in TEST_MEM_MAP,
rimage thinks the whole text section spans from .text to
end of TEST_MEM_MAP, which overlaps .data and others, so
it complains. Skip the execution test to avoid this issue.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
qemu_x86_tiny has very limited memory resources; if too much text is
included in this test, it will not have enough remaining memory to run
it.
When using picolibc before 1.8.5, the only way to get 'long long' support
was to use the full version, including floating point support. This is too
large for this testcase.
Reduce the size of the printf code by switching to the version without
64-bit integer support. This allows the test to pass when using older
picolibc versions, such as that included with SDK version 0.16.3.
Signed-off-by: Keith Packard <keithp@keithp.com>
- Add integration_platforms to avoid excessive filtering
- Make sure integration platforms are actually part of the filter
- Fix some tags and test meta data
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Twister now supports using YAML lists for all fields that were written
as space-separated lists. Used twister_to_list.py script. Some artifacts
on string length are due to how ruamel dumps content.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
With picolibc moving to using the common malloc implementation, samples and
tests with picolibc-specific settings need to switch to using the common
malloc settings instead.
Signed-off-by: Keith Packard <keithp@keithp.com>
The mem_map test was skipped on all the phsical x86 boards when
running twister to test them. This error happens when migrating
the new ztest. Remove the incorrect platform allow to fix this
error.
Signed-off-by: Enjia Mai <enjia.mai@intel.com>
When coverage is enabled on x86_64, GCC uses relative addressing
to increment the gcov counters. The generated code of the test
function assumes execution is in the same location where
the linker places the test function. This does not work with
the execution test as it copies the function into another part
of memory and tries to execute from there. When the copied
function starts to run, the instruction pointer is at the newly
copied function. So any relative addressing with regard to
the instruction pointer now is invalid. Instead of
<generated code RIP + offset> for gcov counter as it should be,
now the copied code is trying to access the counter at
<copied code RIP + offset>, which points to incorrect
memory location (and possibly invalid/non-mapped memory).
To fix this, we need to tell GCC not to use relative addressing.
This can be accomplished by telling GCC to use the large memory
model. This is only used for this test as this option increases
code size quite a bit, and should not be used in general.
Fixes#30434
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This puts the transplanted_function into its own section so that
z_phys_map() can correctly map the whole range of memory used
by the function, in case someone decides to expand the function
to be bigger than a MMU page.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
