This compile test should be checking if a symbol has been defined,
otherwise it is using the kconfig value directly. This fixes a warning
../src/main.c:115:37: warning: "CONFIG_SOC_QEMU_ARC" is not defined,
evaluates to 0 [-Wundef]
when using the -Wundef flag.
Signed-off-by: Bradley Bolen <bbolen@lexmark.com>
qemu arc has limited support for DIV/REM, no DIVZERO exception
throw, so we need to skip trigger_fault_divide_zero test case.
Signed-off-by: Watson Zeng <zhiwei@synopsys.com>
Put the testcase test_catch_assert_in_isr() to execute last, to prevent
it affects other test cases. Because when we caught an assert failure
in the ISR handler, it cannot be guaranteed that all the current
program status would be recovered.
Fixes#34844.
Signed-off-by: Enjia Mai <enjiax.mai@intel.com>
Make the divide instruction not being optimized of the ztest example
test case. Do this because it will be replaced by invalid opcode
exception instruction generated by GCC.
Fixes#33403.
Signed-off-by: Enjia Mai <enjiax.mai@intel.com>
em_starterkit has ICCM at 0x0 address, access to 0x0
address doesn't generate any exception, so we access
to 0xFFFFFFFF address instead to trigger exception.
Signed-off-by: Watson Zeng <zhiwei@synopsys.com>
When running the test on Cortex-M platforms, use access to
_current to trigger a memory access fault, as this address
is guaranteed to be in kernel ram and will not trigger
SecureFault exceptions.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
This functions is being called across the tree, no reason why it should
not be a public API.
The current usage violates a few MISRA rules.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The quirky behavior when accessing of 0x0 address is related to
exact ARC SoCs/boards and not to entire ARC EM CPUs family. So
check for exact SoCs configs (CONFIG_SOC_ARC_IOT and CONFIG_SOC_NSIM)
instead of checking against CONFIG_CPU_ARCEM.
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Minor fixes to the sample output in the README file,
reflecting the correct error reason (3: oops) instead
of reason 0 (generic CPU error).
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
test_catch_z_oops test case should not run in user mode,
since Z_OOPS needs to be called in supervisor mode, otherwise
we will be getting a reguser user memory access error that is
irrelevant to the test case (and simply is triggered by Z_OOPS
accessing the thread's syscall frame pointer).
In addition to that, we fix the argument of Z_OOPS, because, it
was triggering a null-pointer dereferencing, which results in an
error thrown before Z_OOPS is even executed (if null-pointer
exception is caught).
We also need to generate a dummy thread->syscall_frame, that
Z_OOPS implementation will access. We fix this to
_image_ram_start, because this memory is always part of the
image memory and is always available to supervisor mode. So,
accessing it won't trigger a security fault, for example.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
The test case suggests that "For most arch which support
userspace, derefencing NULL pointer will be caught by
exception.". This is certainly not true for Cortex-M, where
read access to address 0x0 is generally allowed. The reason
the test had been passing was either 1) because in many
Cortex-M platforms, including QEMU, address 0x0 is unmapped,
or 2) GCC is generating an undefining instruction. However,
now that we have activated the null pointer derefrencing
detection, we may end up with two exceptions and the test
would fail.
Change illegal access to something outside the mapped memory
area, e.g. 0xFFFFFFFF.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Enlarge the test thread stack size, to fix test case fail
in some board which need more stack size for testing, when
CONFIG_EXCEPTION_DEBUG is enabled.
Signed-off-by: Enjia Mai <enjiax.mai@intel.com>
Fix issue #31339 and #31419, test case fail due to access NULL did not
trigger a fatal error in some platform such as nsim_em and iotdk.
Signed-off-by: Enjia Mai <enjiax.mai@intel.com>
