af37e9d999
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>
21 lines
863 B
YAML
21 lines
863 B
YAML
tests:
|
|
kernel.memory_protection.mem_map:
|
|
tags: kernel mmu ignore_faults
|
|
filter: CONFIG_MMU and not CONFIG_X86_64
|
|
extra_sections: _TRANSPLANTED_FUNC
|
|
platform_exclude: qemu_x86_64
|
|
kernel.memory_protection.mem_map.x86_64:
|
|
tags: kernel mmu ignore_faults
|
|
filter: CONFIG_MMU and CONFIG_X86_64 and not CONFIG_COVERAGE
|
|
extra_sections: _TRANSPLANTED_FUNC
|
|
kernel.memory_protection.mem_map.x86_64.coverage:
|
|
tags: kernel mmu ignore_faults
|
|
filter: CONFIG_MMU and CONFIG_X86_64 and CONFIG_COVERAGE
|
|
extra_sections: _TRANSPLANTED_FUNC
|
|
extra_args: EXTRA_CFLAGS=-DSKIP_EXECUTE_TESTS
|
|
kernel.memory_protection.mem_map.x86_64.coverage.exec:
|
|
tags: kernel mmu ignore_faults
|
|
filter: CONFIG_MMU and CONFIG_X86_64 and CONFIG_COVERAGE
|
|
extra_sections: _TRANSPLANTED_FUNC
|
|
extra_args: CONF_FILE=prj_x86_64_coverage_exec.conf
|