Lines Matching +full:overflow +full:- +full:control
13 * ARMv7-M ISA with Thumb2 instruction set and ARM Embedded ABI (aeabi)
33 and architecture-dependent, and thread abortion possibly as well (required).
39 architecture-specific implementation for performance reasons (required).
44 * **Fault management**: for implementing architecture-specific debug help and
47 * **Linker scripts and toolchains**: architecture-specific details will most
50 * **Memory Management and Memory Mapping**: for architecture-specific details
53 * **Stack Objects**: for architecture-specific details on memory protection
71 * If running an :abbr:`XIP (eXecute-In-Place)` kernel, copy initialized data
79 Some examples of architecture-specific steps that have to be taken:
81 * If given control in real mode on x86_32, switch to 32-bit protected mode.
84 * Initialize a board-specific watchdog on Cortex-M3/4.
85 * Switch stacks from MSP to PSP on Cortex-M.
86 * Use a different approach than calling into _Swap() on Cortex-M to prevent
98 Both, interrupts and exceptions, pass control to a handler. The handler is
101 interrupt. For interrupts, that work is device-specific. For exceptions, it
108 * Prior to handing control to the handler:
115 * After getting control back from the handler:
129 It thus needs an architecture-specific implementation, called the
134 .. code-block:: C
143 the stub. This is commonly found in X86-based architectures.
155 Each architecture also has to implement primitives for interrupt control:
171 is a fault, like divide-by-zero or invalid memory access, or an interrupt that
178 Multi-threading is the basic purpose to have a kernel at all. Zephyr supports
213 control to another thread. There are two cases where this happens
227 Control is never taken from cooperative thread when one of them is the
243 neither the ARM Cortex-M or ARCv2 port do this.
245 Since :code:`_Swap` is cooperative, the caller-saved registers from the ABI are
260 similar to locking the interrupts, but lighter-weight since interrupts can
262 non-preemptible.
279 If running a coop-only system, i.e. if :kconfig:option:`CONFIG_NUM_PREEMPT_PRIORITIES`
288 context switched out. This is to be implemented in an architecture-specific
298 The need for an architecture-specific thread termination implementation depends
302 One reason that has been encountered for having an architecture-specific
305 This is the case for ARM Cortex-M, where the CPU has to be taken out of handler
309 This means implementing an architecture-specific version of
357 On the other hand, the ARM Cortex-M has the :abbr:`NVIC (Nested Vectored
359 for an IDT-like table that is separate from the NVIC vector table. The position
361 programmable per-entry.
365 having a one-to-one mapping between exception and interrupt numbers (i.e.
368 IRQ-15).
377 Cortex-M has the SYSTICK exception. Finally, ARCv2 has the timer0/1 device.
387 port, since it is so useful for debugging. It is a simple polling, output-only,
399 instructions or in a lock-less manner in modern processors. Those are thus
410 around non-atomic operations exists. It is configured using the
413 * Find-least-significant-bit-set and find-most-significant-bit-set.
418 It is possible to use compiler built-ins to implement these, but be careful
434 * In a single-threaded system, in the only thread when the thread is not used
441 re-enable interrupts and invoke the power saving instruction. It can thus be
442 used in real application code, again in single-threaded systems.
460 out architecture-agnostic information and makes a policy
462 This function can be overridden to implement application-specific
472 Some architecture-specific definitions are needed in :zephyr_file:`include/zephyr/toolchain/gcc.h`.
483 If the target platform enables paging and requires drivers to memory-map
487 - :c:func:`arch_mem_map`
488 - :c:func:`arch_mem_unmap`
489 - :c:func:`arch_page_phys_get`
502 - "kernel" stacks defined with :c:macro:`K_KERNEL_STACK_DEFINE()` and related
508 - "thread" stacks which typically use more memory, but are capable of hosting
509 thread running in user mode, as well as any use-cases for kernel stacks.
520 - :c:macro:`ARCH_KERNEL_STACK_RESERVED`: default no reserved space
521 - :c:macro:`ARCH_THREAD_STACK_RESERVED`: default no reserved space
522 - :c:macro:`ARCH_KERNEL_STACK_OBJ_ALIGN`: default align to
524 - :c:macro:`ARCH_THREAD_STACK_OBJ_ALIGN`: default align to
526 - :c:macro:`ARCH_THREAD_STACK_SIZE_ALIGN`: default round up to
532 zero-sized depending on configuration. There are always two main parts:
538 Some architectures may need to carve-out reserved memory at runtime from the
541 Such carve-outs will always be tracked in ``thread.stack_info.start``.
548 .. code-block:: none
550 +---------------------+ <- thread.stack_obj
552 +---------------------+
553 | Carved-out memory |
554 |.....................| <- thread.stack_info.start
557 |.....................| <- thread's current stack pointer
560 |.....................| <- Initial stack pointer. Computable
562 +---------------------| <- thread.userspace_local_data
563 | Thread-local data |
564 +---------------------+ <- thread.stack_info.start + thread.stack_info.size
574 HW-based stack overflow detection
582 * The kernel could have been inside a critical section when the overflow
590 provide some kind of hardware-based stack overflow protection, and enable the
593 Two forms of HW-based stack overflow detection are supported: dedicated
594 CPU features for this purpose, or special read-only guard regions immediately
598 supervisor threads. This is not required to catch stack overflow from user
603 not been corrupted. Any stack overflow in supervisor mode should be treated as
611 CPU-based stack overflow detection
612 ----------------------------------
619 Guard-based stack overflow detection
620 ------------------------------------
631 MMU-based systems should not reserve RAM for the guard region and instead
632 simply leave an non-present virtual page below every stack when it is mapped
636 .. code-block:: none
638 +-----------------------------+ <- thread.stack_obj
640 +-----------------------------+
641 | Guard carve-out |
642 |.............................| <- thread.stack_info.start
646 Guard carve-outs for kernel stacks are uncommon and should be avoided if
649 * The same stack may be re-purposed to host a user thread, in which case
657 completely overshooting a minimally-sized guard and corrupting adjacent
666 * A separate fixed-sized privilege mode stack, specified by
670 be able to be placed before it, with support for carve-outs if necessary.
684 ``thread.stack_info`` always tracks the user-accessible part of the stack
688 Non power-of-two memory region requirements
689 -------------------------------------------
691 On systems without power-of-two region requirements, the reserved memory area
695 .. code-block:: none
697 +------------------------------+ <- thread.stack_obj
699 +------------------------------+
701 +------------------------------+
702 | Guard carve-out (if needed) |
705 +------------------------------| <- thread.stack_obj +
709 The guard region, and any carve-out (if needed) would be configured as a
710 read-only region when the thread is created.
713 extra stack memory. An overflow will eventually crash into the guard region.
717 before or after it. An overflow in user mode will crash into the privilege
718 elevation stack, which the user thread has no access to. An overflow when
723 memory, each with non-present virtual guard pages below them to catch runtime
735 Power-of-two memory region requirements
736 ---------------------------------------
748 enabled. For every thread stack found in the system, a corresponding fixed-size
752 laid out the same way as other kernel-only stacks.
754 .. code-block:: none
756 +-----------------------------+ <- z_priv_stack_find(thread.stack_obj)
758 +-----------------------------+
759 | Guard carve-out (if needed) |
763 +-----------------------------+ <- z_priv_stack_find(thread.stack_obj) +
767 +-----------------------------+ <- thread.stack_obj
768 | MPU guard carve-out |
770 |.............................| <- thread.stack_info.start
774 The guard carve-out in the thread stack object is only used if the thread is
782 To support user mode threads, several kernel-to-arch APIs need to be
922 the G-packet is architecture specific. Consult GDB on what is
925 * Note that, for most architectures, a valid G-packet must be returned
931 * This takes a G-packet sent by GDB and populates the hardware
932 registers with values from the G-packet.
978 * :c:macro:`GDB_MEM_REGION_RO`: region is read-only.
980 * :c:macro:`GDB_MEM_REGION_RW`: region is read-write.
984 and read/write can be done byte-by-byte.
992 .. doxygengroup:: arch-timing
997 .. doxygengroup:: arch-threads
999 .. doxygengroup:: arch-tls
1004 .. doxygengroup:: arch-pm
1006 Symmetric Multi-Processing
1009 .. doxygengroup:: arch-smp
1014 .. doxygengroup:: arch-irq
1019 .. doxygengroup:: arch-userspace
1024 .. doxygengroup:: arch-mmu
1029 .. doxygengroup:: arch-misc
1034 .. doxygengroup:: arch-gdbstub