This commit makes it possible to infer Z_ARCH_EXCEPT()
calls in SVCs that escalate to HardFault due to being
invoked from priority level equal or higher to the
interrupt priority level of the SVC Handler.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Consistently place C++ use of extern "C" after all include directives,
within the negative branch of _ASMLANGUAGE if used.
In arch.h the extern "C" in the including context is left active during
include of target-specific mpu headers to avoid more complex
restructuring.
Background from issue #17997:
Declarations that use C linkage should be placed within extern "C"
so the language linkage is correct when the header is included by
a C++ compiler.
Similarly #include directives should be outside the extern "C" to
ensure the language-specific default linkage is applied to any
declarations provided by the included header.
See: https://en.cppreference.com/w/cpp/language/language_linkage
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
'recoverable' is a value passed by reference and we
should be dereferencing the pointer, to check if the
fault has been classified as recoverable.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
This commit enables the option to route the BusFault,
HardFault, and NMI exceptions in Secure state, when
building for Cortex-M CPUs with ARM_SECURE_FIRMWARE=y.
This allows the various test to utilize BusFault,
HardFault and NMI exceptions during testing.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Since commit c535300539 ("drivers/timer: New ARM SysTick driver"),
_NanoIdleValGet and _NanoIdleValClear have been unused.
Signed-off-by: Bradley Bolen <bbolen@lexmark.com>
The current API was assuming too much, in that it expected that
arch-specific memory domain configuration is only maintained
in some global area, and updates to domains that are not currently
active have no effect.
This was true when all memory domain state was tracked in page
tables or MPU registers, but no longer works when arch-specific
memory management information is stored in thread-specific areas.
This is needed for: #13441#13074#15135
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
The ARM specific _impl_k_thread_abort function only applies to Cortex-M
so move it to the cortex_m specific directory.
Signed-off-by: Bradley Bolen <bbolen@lexmark.com>
User mode is only allowed to induce oopses and stack check
failures via software-triggered system fatal exceptions. This
commit forces a kernel oops if any other fatal exception reason
is enforced.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
This is now called z_arch_esf_t, conforming to our naming
convention.
This needs to remain a typedef due to how our offset generation
header mechanism works.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
We had a function that did this, but it was dead code.
Move to fatal.c and call from z_arm_fatal_error().
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
We introduce a new z_fatal_print() API and replace all
occurrences of exception handling code to use it.
This routes messages to the logging subsystem if enabled.
Otherwise, messages are sent to printk().
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
* z_NanoFatalErrorHandler() is now moved to common kernel code
and renamed z_fatal_error(). Arches dump arch-specific info
before calling.
* z_SysFatalErrorHandler() is now moved to common kernel code
and renamed k_sys_fatal_error_handler(). It is now much simpler;
the default policy is simply to lock interrupts and halt the system.
If an implementation of this function returns, then the currently
running thread is aborted.
* New arch-specific APIs introduced:
- z_arch_system_halt() simply powers off or halts the system.
* We now have a standard set of fatal exception reason codes,
namespaced under K_ERR_*
* CONFIG_SIMPLE_FATAL_ERROR_HANDLER deleted
* LOG_PANIC() calls moved to k_sys_fatal_error_handler()
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
We are standardizing to a arch-independent set of exception
reason codes, don't overload it with internal state of
the ARM fault handling code.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Qemu is already updated past 2.9 release, so this
workaround for QEMU_CORTEX_M3 is now obsolete and
can be removed.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
z_arm_do_syscall is executing in privileged mode. This implies
that we shall not be allowed to use the thread's default
unprivileged stack, (i.e push to or pop from it), to avoid any
possible stack corruptions.
Note that since we execute in PRIV mode and no MPU guard or
PSPLIM register is guarding the end of the default stack, we
won't be able to detect any stack overflows.
This commit implement the above change, by forcing
z_arm_do_syscall() to FIRST switch to privileged
stack and then do all the preparations to execute
the system call.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
We need to correct the inline comment in swap_helper.S,
which is suggesting that system call attempts with
invalid syscall IDs (i.e. above the limit) do not force
the CPU to elevate privileges. This is in fact not true,
since the execution flow moves into valid syscall ID
handling.
In other words, all we do for system calls with invalid
ID numbers is to treat them as valid syscalls with the
K_SYSCALL_BAD ID value.
We fix the inline documentation to reflect the actual
execution flow.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
System call arguments are indexed from 1 to 6, so arg0
is corrected to arg1 in two occasions. In addition, the
ARM function for system calls is now called z_arm_do_syscall,
so we update the inline comment in __svc handler.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
ARMv8-M architecture supports the built-in stack overflow
detection mechanisms via the SPLIM registers. However, the
user might still wish to use the traditional MPU-based stack
overflow detection mechanism (for testing or other reasons).
We now allow the user to enable HW stack protection, but
manually turn off BUILTIN_STACK_GUARD option. This will force
the MPU_STACK_GUARD option to be selected.
It is still not allowed for the user to not select any stack
guard mechanisms, if HW_STACK_PROTECTION is selected.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Fix the start of the guard to take into account the
configurable size of the guard.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
move misc/reboot.h to power/reboot.h and
create a shim for backward-compatibility.
No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.
Related to #16539
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
move misc/util.h to sys/util.h and
create a shim for backward-compatibility.
No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.
Related to #16539
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
move misc/printk.h to sys/printk.h and
create a shim for backward-compatibility.
No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.
Related to #16539
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
move misc/dlist.h to sys/dlist.h and
create a shim for backward-compatibility.
No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.
Related to #16539
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
move misc/__assert.h to sys/__assert.h and
create a shim for backward-compatibility.
No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.
Related to #16539
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
move atomic.h to sys/atomic.h and
create a shim for backward-compatibility.
No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.
Related to #16539
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
move tracing.h to debug/tracing.h and
create a shim for backward-compatibility.
No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.
Related to #16539
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Under FP shared registers mode (CONFIG_FP_SHARING=y),
a thread's user_options flag is checked during swap and
during stack fail check. Therefore, in k_float_disable()
we want to ensure that a thread won't be swapped-out with
K_FP_REGS flag cleared but still FP-active (CONTROL.FPCA
being not zero). To ensure that we temporarily disable
interrupts.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
This commit reworks the ARM stack fail checking, under FP
Sharing registers mode, to account for the right width of
the MPU stack guard.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
For threads that appear to be FP-capable (i.e. with K_FP_REGS
option flag set), we configure a wide MPU stack guard, if we
build with stack protection enabled (CONFIG_MPU_STACK_GUARD=y).
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
When an FP capable thread (i.e. with K_FP_REGS option)
transitions into user mode, we want to allocate a wider
MPU stack guard region, to be able to successfully detect
overflows of the privilege stack during system calls. For
that we also need to re-adjust the .priv_stack_start pointer,
which denotes the start of the writable area of the privilege
stack buffer.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
When an FP capable thread is created (i.e. with K_FP_REGS
option) we want to allocate a wider MPU stack guard region,
to be able to successfully detect stack overflows. For that
we also need to re-adjust the values that will be passed to
the thread's stack_info .start and .size parameters.
applicable) for a thread which intends to use the FP services.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Compilers (at least gcc and clang) already provide definitions to
create standard types and their range. For example, __INT16_TYPE__ is
normally defined as a short to be used with the int16_t typedef, and
__INT16_MAX__ is defined as 32767. So it makes sense to rely on them
rather than hardcoding our own, especially for the fast types where
the compiler itself knows what basic type is best.
Using compiler provided definitions makes even more sense when dealing
with 64-bit targets where some types such as intptr_t and size_t must
have a different size and range. Those definitions are then adjusted
by the compiler directly.
However there are two cases for which we should override those
definitions:
* The __INT32_TYPE__ definition on 32-bit targets vary between an int
and a long int depending on the architecture and configuration.
Notably, all compilers shipped with the Zephyr SDK, except for the
i586-zephyr-elfiamcu variant, define __INT32_TYPE__ to a long int.
Whereas, all Linux configurations for gcc, both 32-bit and 64-bit,
always define __INT32_TYPE__ as an int. Having variability here is
not welcome as pointers to a long int and to an int are not deemed
compatible by the compiler, and printing an int32_t defined with a
long using %d makes the compiler to complain, even if they're the
same size on 32-bit targets. Given that an int is always 32 bits
on all targets we might care about, and given that Zephyr hardcoded
int32_t to an int before, then we just redefine __INT32_TYPE__ and
derrivatives to an int to keep the peace in the code.
* The confusion also exists with __INTPTR_TYPE__. Looking again at the
Zephyr SDK, it is defined as an int, even even when __INT32_TYPE__ is
initially a long int. One notable exception is i586-zephyr-elf where
__INTPTR_TYPE__ is a long int even when using -m32. On 64-bit targets
this is always a long int. So let's redefine __INTPTR_TYPE__ to always
be a long int on Zephyr which simplifies the code, works for both
32-bit and 64-bit targets, and mimics what the Linux kernel does.
Only a few print format strings needed adjustment.
In those two cases, there is a safeguard to ensure the type we're
enforcing has the right size and fail the build otherwise.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
This commit aligns the programming of the privileged stack MPU
guard with that of the default stack guard (i.e of supervisor
threads). In particular:
- the guard is programmed BELOW the address indicated in
arch.priv_stack_start; it is, therefore, similar to the
default guard that is programmed BELOW stack_info.start.
An ASSERT is added to confirm that the guard is programmed
inside the thread privilege stack area.
- the stack fail check is updated accordningly
- arch.priv_stack_start is adjusted in arch_userspace_enter(),
to make sure we account for a (possible) guard requirement,
that is, if building with CONFIG_MPU_STACK_GUARD=y.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
This commit re-organizes the macro definitions in arch.h for
the ARM architecture. In particular, the commit:
- defines the minimum alignment requirement for thread stacks,
that is, excluding alignment requirement for (possible)
MPU stack guards.
- defines convenience macros for the MPU stack guard align and
size for threads using the FP services under Shared registers
mode (CONFIG_FP_SHARING=y). For that, a hidden Kconfig option
is defined in arch/arm/core/cortex_m/mpu/Kconfig.
- enforces stack alignment with a wide MPU stack guard (128
bytes) under CONFIG_FP_SHARING=y for the ARMv7-M architecture,
which requires start address alignment with power-of-two and
region size.
The commit does not change the amount of stack that is reserved
with K_THREAD_STACK_DEFINE; it only determines the stack buffer
alignment as explained above.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Found a few annoying typos and figured I better run script and
fix anything it can find, here are the results...
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This commit adds the architecture-specific implementation
of k_float_disable() for ARM and x86.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
When building without support for user mode (CONFIG_USERSPACE=n)
we need to correct the starting address of the MPU Guard, before
passing it to the function that evaluates whether a stack
corruption has occurred. The bug was introduced by commit
(60bae5de38) in
PR-13619, where the start address of the MPU guard was properly
corrected, but the guard start at the corresponding stack-fail
check was not adjusted accordingly.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Change removes tracing hooks before threads are initialized
and thread switched out hook for ARM before first time switching
to main thread.
Signed-off-by: Marek Pieta <Marek.Pieta@nordicsemi.no>
ip register holds the stack_info.size (it is passed as argument
into z_arch_user_mode_enter(.)). We trust that the value of
stack_info.size contains the accurate size of the writable
stack buffer, above stack_info.start (as specified in kernel.h).
Therefore, we do not need to subtract any bytes for the MPU
stack guard. This allows us to clean-up one more occurrence of
CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT in userspace.S.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
arm_core_mpu_enable() and arm_core_mpu_disable() functions are
effectively static functions, only used in the drivers for ARM
and NXP MPU, therefore, we do not need to expose them in the
arm_core_mpu_dev.h header.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Andrew Boie