[Valgrind-developers] Stack switches vs stack growth/shrinkage

[Jeremy F. <je...@go...>]

Valgrind has a problem in being able to distinguish between large stack
adjustments and stack switches.  At the moment, the core has a heuristic
based on the size of %esp delta.  As shown by UML's use of stacks, this
heuristic doesn't work reliably when you have a number of densely packed
small stacks.

It seems to me that the core can't really distinguish between these two
types of esp updates.  The only skins which really care about the
distinction are memcheck and addrcheck, because they keep information
about which parts of the address space are validly addressable, and
which parts aren't. They can, however, use their address validity
information to make the distinction between the two cases.

When extending the stack, the effect is to increase the range valid
addresses down from the old esp to the new esp; similarly, shrinking the
stack invalidates the addresses between the old esp and the new esp.  It
seems to me that the correct check to apply is to see if there are
already some valid/invalid addresses in that range; if so, this is a
stack switch; if not, it is a stack extension/contraction.  

The rationale is that if one is apparently extending the stack over some
already valid memory, it can't be an actual stack extension, because it
means you're extending over some previously valid data structures. 
Similarly, a stack can't have invalid addresses embedded in it, so if
there appear to be some, it is probably another stack.

Of course, an actually buggy program which underflows or overflows its
stack would incorrectly look like a stack switch, but with luck the
other checking mechanisms would detect and report this as an error.

	J