Improve stack guard page handling on ARM

[wma]

Summary

When the stack overflows (from the function recursion, for example)
the Stack Pointer pointing to unmapped memory page will cause a rolling
data abort. The PUSHFRAMEINSVC will constantly try to put the system
state on the stack and decrease SP until any valid VM address is found.
Then, all data present at this address will be corrupted by the
data_abort and panic functions.

To prevent from that situation, declare a special stack to handle this
situation. When the PUSHFRAMEINSVC detects that stack pointer falls
into the faulty page (by comparing with FAR) it swaps the stack
to the  backup "guard stack". That allows executing of C-code
and handling the error further. Detecting this is fairly easy,
we need to check if data_abort function has its stack frame
located inside a "guard stack". That is done by comparing a pointer
of a variable with address of global "guard stack" area.

[wma]

Cleaning up.

[wma]

Any comments?

[mmel]

[mmel]

Hmm, i have some problems with this:

1. DFAR is not valid in all cases. Please see table B3-26 in ARM ARM (ARM DDI 0406C.c)
2. The patch adds significant amount of instructions into hot path , so i think that this check must be covered by INVARIANTS
3. You are already on abort stack and all checks can be done on it. Why do you need next one?

Imho, something like:

#ifdef INVARIANTS
.if \gp == DATA_ABORT

        <save registers>
        <switch back to abort mode & stack>
        <call C function to check SVC stack>
        <switch to SVC mode & stack>
        <restore registers>

.endif
#endif

And sorry for edit, I sent incomplete comment by mistake...

[wma]

Obsoleted