|
From: Jeremy F. <je...@go...> - 2002-12-28 04:44:49
|
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 |