Memory Layout
This page is intended to give a relatively high-level overview of the memory layout used by Ariel OS across processor architectures and MCU families. Minor variations across them are omitted for clarity. Additionally, no stability guarantees are currently provided regarding the memory layout.
Tip
If needed, the following command can be used to obtain the exact locations of sections:
readelf --sections <path-to-elf>
- On architectures and MCUs that allow it1, Ariel OS places the ISR stack,
.isr_stack, at the very beginning of the RAM. This provides a form of stack overflow protection, as write attempts would then collide with the boundary of the physical RAM and trigger a fault, instead of overwritingstaticdata. See theflip-linkcrate for an explanation of the technique. The ISR stack is named.stackon Xtensa, and may not be placed at the beginning of the RAM nor before the.datasection. - Async tasks are allocated statically, as individual
statics, anywhere in the.bsssection. - The thread stacks, if multithreading is enabled, are currently allocated as individual
statics, anywhere in the.bsssection. - If multithreading is enabled, and if the MCU has two symmetrical cores and
multi-coreis enabled, the ISR stack of the second core is allocated as astatic, anywhere in the.bsssection. - Depending on the architecture, the uninitialized section is either called
.uninitor.noinit. - The heap, if enabled, may take up to the remaining space.
heapsize_requiredensures that there is enough space for the heap, at link time.
.-------------. - beginning of RAM
| ⋮ |
+-------------+ -
| |
| | | ^
Addresses| | .isr_stack | | ≥ isr_stacksize_required + executor_stacksize_required
v | | v
| |
+-------------+ -
| |
| |
| | .- - .-------------.
| | | | ⋮ |
| .data | | +-------------+
| | | | Async |
| | | | tasks |
| | | | ... |
| | | +-------------+
+-------------+ - -' | ⋮ |
| | +-------------+
| | | [Thread |
| .bss | | stacks |
| | | ...] |
| | +-------------+
+-------------+ - -. | ⋮ |
| | '- - '-------------'
| .uninit |
| or |
| .noinit |
| |
+-------------+ -
| |
| |
' ' ^
| | |
' [Heap] ' | ≥ "heapsize_required"
| | |
' ' v
| |
| |
'-------------' - end of RAM
executor-interrupt
.-------------. - beginning of RAM
| ⋮ |
+-------------+ -
| |
| | | ^
Addresses| | .isr_stack | | ≥ "isr_stacksize_required"
v | | v
| |
+-------------+ -
| |
| |
| | .- - .-------------.
| | | | ⋮ |
| | | +-------------+
| .data | | | Async |
| | | | tasks |
| | | | ... |
| | | +-------------+
| | | | ⋮ |
| | | +-------------+ -
+-------------+ - -' | Executor | ^
| | | thread | | ≥ "executor_stacksize_required"
| | | stack | v
| | +-------------+ -
| .bss | | ⋮ |
| | +-------------+
| | | [Thread |
| | | stacks |
+-------------+ - -. | ...] |
| | | +-------------+
| | | | ⋮ |
| .uninit | '- - '-------------'
| or |
| .noinit |
| |
| |
+-------------+ -
| |
| |
' ' ^
| | |
' [Heap] ' | ≥ "heapsize_required"
| | |
' ' v
| |
| |
'-------------' - end of RAM
executor-thread-
Currently that is Cortex-M-based MCUs and some RISC-V based ESP32s (the ESP32-C6, but not the ESP32-C3). ↩