[444] | 1 | #include "arm.h" |
---|
| 2 | /* Run-time exception support */ |
---|
| 3 | #ifndef PREFER_THUMB |
---|
| 4 | #include "swi.h" |
---|
| 5 | |
---|
| 6 | /* .text is used instead of .section .text so it works with arm-aout too. */ |
---|
| 7 | .text |
---|
| 8 | .align 0 |
---|
| 9 | .global __rt_stkovf_split_big |
---|
| 10 | .global __rt_stkovf_split_small |
---|
| 11 | |
---|
| 12 | /* The following functions are provided for software stack checking. |
---|
| 13 | If hardware stack-checking is being used then the code can be |
---|
| 14 | compiled without the PCS entry checks, and simply rely on VM |
---|
| 15 | management to extend the stack for a thread. |
---|
| 16 | |
---|
| 17 | The stack extension event occurs when the PCS function entry code |
---|
| 18 | would result in a stack-pointer beneath the stack-limit register |
---|
| 19 | value. The system relies on the following map: |
---|
| 20 | |
---|
| 21 | +-----------------------------------+ <-- end of stack block |
---|
| 22 | | ... | |
---|
| 23 | | ... | |
---|
| 24 | | active stack | |
---|
| 25 | | ... | <-- sp (stack-pointer) somewhere in here |
---|
| 26 | | ... | |
---|
| 27 | +-----------------------------------+ <-- sl (stack-limit) |
---|
| 28 | | stack-extension handler workspace | |
---|
| 29 | +-----------------------------------+ <-- base of stack block |
---|
| 30 | |
---|
| 31 | The "stack-extension handler workspace" is an amount of memory in |
---|
| 32 | which the stack overflow support code must execute. It must be |
---|
| 33 | large enough to deal with the worst case path through the extension |
---|
| 34 | code. At the moment the compiler expects this to be AT LEAST |
---|
| 35 | 256bytes. It uses this fact to code functions with small local |
---|
| 36 | data usage within the overflow space. |
---|
| 37 | |
---|
| 38 | In a true target environment We may need to increase the space |
---|
| 39 | between sl and the true limit to allow for the stack extension |
---|
| 40 | code, SWI handlers and for undefined instruction handlers of the |
---|
| 41 | target environment. */ |
---|
| 42 | |
---|
| 43 | __rt_stkovf_split_small: |
---|
| 44 | mov ip,sp @ Ensure we can calculate the stack required |
---|
| 45 | @ and fall through to... |
---|
| 46 | __rt_stkovf_split_big: |
---|
| 47 | @ in: sp = current stack-pointer (beneath stack-limit) |
---|
| 48 | @ sl = current stack-limit |
---|
| 49 | @ ip = low stack point we require for the current function |
---|
| 50 | @ lr = return address into the current function |
---|
| 51 | @ fp = frame-pointer |
---|
| 52 | @ original sp --> +----------------------------------+ |
---|
| 53 | @ | pc (12 ahead of PCS entry store) | |
---|
| 54 | @ current fp ---> +----------------------------------+ |
---|
| 55 | @ | lr (on entry) pc (on exit) | |
---|
| 56 | @ +----------------------------------+ |
---|
| 57 | @ | sp ("original sp" on entry) | |
---|
| 58 | @ +----------------------------------+ |
---|
| 59 | @ | fp (on entry to function) | |
---|
| 60 | @ +----------------------------------+ |
---|
| 61 | @ | | |
---|
| 62 | @ | ..argument and work registers.. | |
---|
| 63 | @ | | |
---|
| 64 | @ current sp ---> +----------------------------------+ |
---|
| 65 | @ |
---|
| 66 | @ The "current sl" is somewhere between "original sp" and "current sp" |
---|
| 67 | @ but above "true sl". The "current sl" should be at least 256bytes |
---|
| 68 | @ above the "true sl". The 256byte stack guard should be large enough |
---|
| 69 | @ to deal with the worst case function entry stacking (160bytes) plus |
---|
| 70 | @ the stack overflow handler stacking requirements, plus the stack |
---|
| 71 | @ required for the memory allocation routines. |
---|
| 72 | @ |
---|
| 73 | @ Normal PCS entry (before stack overflow check) can stack 16 |
---|
| 74 | @ standard registers (64bytes) and 8 floating point registers |
---|
| 75 | @ (96bytes). This gives a minimum stack guard of 160bytes (excluding |
---|
| 76 | @ the stack required for the code). (Actually only a maximum of |
---|
| 77 | @ 14standard registers are ever stacked on entry to a function). |
---|
| 78 | @ |
---|
| 79 | @ NOTE: Structure returns are performed by the caller allocating a |
---|
| 80 | @ dummy space on the stack and passing in a "phantom" arg1 into |
---|
| 81 | @ the function. This means that we do not need to worry about |
---|
| 82 | @ preserving the stack under "sp" even on function return. |
---|
| 83 | @ |
---|
| 84 | @ Code should never poke values beneath sp. The sp register |
---|
| 85 | @ should always be "dropped" first to cover the data. This |
---|
| 86 | @ protects the data against any events that may try and use |
---|
| 87 | @ the stack. |
---|
| 88 | |
---|
| 89 | SUB ip, sp, ip @ extra stack required for function |
---|
| 90 | @ Add stack extension code here. If desired a new stack chunk |
---|
| 91 | @ can be allocated, and the register state updated suitably. |
---|
| 92 | |
---|
| 93 | @ We now know how much extra stack the function requires. |
---|
| 94 | @ Terminate the program for the moment: |
---|
| 95 | swi SWI_Exit |
---|
| 96 | #endif |
---|