check for stack alloc of addressable memory in fastpath

_From [derek.br...@gmail.com](https://code.google.com/u/117968039472581148324/) on December 10, 2010 17:58:20_

PR 542004

To detect unknown stacks, and attempt to prevent a too-large
stack swap threshold, when we see a push of addressable memory
we check whether we should act (PR 525807). But the app can use the stack
for a while before it invokes a push, especially on x64 where pushes are
rarely used. This case covers inserting a check into the esp adjust
fastpath. It will be expensive for 32-bit but not as critical there: stack
adjusts should be rarer for 64-bit so it may be tolerable there.

Should also use the confirmed stack swap point to mark region below target as
UNADDR instead of waiting for push or alloc of addr

expanding on comment `#1`:
/\* FIXME PR 542004: instead of waiting for push of addr memory and
\* handle_push_addressable(), we should mark below new_xsp as unaddr here:
\* but are we sure the app is using this as a stack? It's possible it's in
\* an optimized loop and it's using xsp as a general-purpose register.
*/

and expanding this PR to include other improvements on PR 525807 such as:
/\* We don't nec. know the stack bounds since some apps malloc
\* a struct that has some fields and then a stack, so we do one
\* page at a time. Alternatives include:
\* - have an API where the app tells us its stack bounds: or if
\* constant could just be a runtime option
\* - stop if hit a defined shadow value before the page size. can
\* only do this on 1st time to rule out stale stack values that
\* can happen if swaps include rollbacks (e.g., swap to base like
\* DR does w/ dstack, or longjmp from sigaltstack). thus would
\* need to remember every stack (and remove from data struct on
\* dealloc).
*/

_Original issue: http://code.google.com/p/drmemory/issues/detail?id=184_