a7364adeb9
* arm/crt0.S: Copied from newlib and it now also sets up stacks for
FIQ and IRQ mode, plus calls hardware_init_hook() and
software_init_hook() if present.
* arm/libcfunc.c, arm/swi.h, arm/syscalls.c: Copied
from newlib.
* arm/Makefile.in: Build crt0.o, rdpmon-crt0.o, rdimon-crt0.o,
librdpmon.a, librdimon.a - support file for "bare" setup, as well
as "RDP" and "RDI" monitors.
* arm/coff-rdpmon.specs, arm/elf-rdpmon.specs,
arm/coff-rdimon.specs, arm/elf-rdimon.specs: gcc specs files to go
with above mentioned support libs and startfiles.
94 lines
4.9 KiB
ArmAsm
94 lines
4.9 KiB
ArmAsm
/* Run-time exception support */
|
|
#include "swi.h"
|
|
|
|
/* .text is used instead of .section .text so it works with arm-aout too. */
|
|
.text
|
|
.align 0
|
|
.global __rt_stkovf_split_big
|
|
.global __rt_stkovf_split_small
|
|
|
|
/* The following functions are provided for software stack checking.
|
|
If hardware stack-checking is being used then the code can be
|
|
compiled without the PCS entry checks, and simply rely on VM
|
|
management to extend the stack for a thread.
|
|
|
|
The stack extension event occurs when the PCS function entry code
|
|
would result in a stack-pointer beneath the stack-limit register
|
|
value. The system relies on the following map:
|
|
|
|
+-----------------------------------+ <-- end of stack block
|
|
| ... |
|
|
| ... |
|
|
| active stack |
|
|
| ... | <-- sp (stack-pointer) somewhere in here
|
|
| ... |
|
|
+-----------------------------------+ <-- sl (stack-limit)
|
|
| stack-extension handler workspace |
|
|
+-----------------------------------+ <-- base of stack block
|
|
|
|
The "stack-extension handler workspace" is an amount of memory in
|
|
which the stack overflow support code must execute. It must be
|
|
large enough to deal with the worst case path through the extension
|
|
code. At the moment the compiler expects this to be AT LEAST
|
|
256bytes. It uses this fact to code functions with small local
|
|
data usage within the overflow space.
|
|
|
|
In a true target environment We may need to increase the space
|
|
between sl and the true limit to allow for the stack extension
|
|
code, SWI handlers and for undefined instruction handlers of the
|
|
target environment. */
|
|
|
|
__rt_stkovf_split_small:
|
|
mov ip,sp @ Ensure we can calculate the stack required
|
|
@ and fall through to...
|
|
__rt_stkovf_split_big:
|
|
@ in: sp = current stack-pointer (beneath stack-limit)
|
|
@ sl = current stack-limit
|
|
@ ip = low stack point we require for the current function
|
|
@ lr = return address into the current function
|
|
@ fp = frame-pointer
|
|
@ original sp --> +----------------------------------+
|
|
@ | pc (12 ahead of PCS entry store) |
|
|
@ current fp ---> +----------------------------------+
|
|
@ | lr (on entry) pc (on exit) |
|
|
@ +----------------------------------+
|
|
@ | sp ("original sp" on entry) |
|
|
@ +----------------------------------+
|
|
@ | fp (on entry to function) |
|
|
@ +----------------------------------+
|
|
@ | |
|
|
@ | ..argument and work registers.. |
|
|
@ | |
|
|
@ current sp ---> +----------------------------------+
|
|
@
|
|
@ The "current sl" is somewhere between "original sp" and "current sp"
|
|
@ but above "true sl". The "current sl" should be at least 256bytes
|
|
@ above the "true sl". The 256byte stack guard should be large enough
|
|
@ to deal with the worst case function entry stacking (160bytes) plus
|
|
@ the stack overflow handler stacking requirements, plus the stack
|
|
@ required for the memory allocation routines.
|
|
@
|
|
@ Normal PCS entry (before stack overflow check) can stack 16
|
|
@ standard registers (64bytes) and 8 floating point registers
|
|
@ (96bytes). This gives a minimum stack guard of 160bytes (excluding
|
|
@ the stack required for the code). (Actually only a maximum of
|
|
@ 14standard registers are ever stacked on entry to a function).
|
|
@
|
|
@ NOTE: Structure returns are performed by the caller allocating a
|
|
@ dummy space on the stack and passing in a "phantom" arg1 into
|
|
@ the function. This means that we do not need to worry about
|
|
@ preserving the stack under "sp" even on function return.
|
|
@
|
|
@ Code should never poke values beneath sp. The sp register
|
|
@ should always be "dropped" first to cover the data. This
|
|
@ protects the data against any events that may try and use
|
|
@ the stack.
|
|
|
|
SUB ip, sp, ip @ extra stack required for function
|
|
@ Add stack extension code here. If desired a new stack chunk
|
|
@ can be allocated, and the register state updated suitably.
|
|
|
|
@ We now know how much extra stack the function requires.
|
|
@ Terminate the program for the moment:
|
|
swi SWI_Exit
|