> > * This might give a bit of a performance hit in unwind- > > intensive programs as the stacks list now has to be searched for > > each snapshot. I guess we could mostly ameliorate this by the > > usual trick of incrementally rearranging the list to diffuse > > frequently-requested entries towards the front. > > It may be an issue, yes. In fact my original solution to the > problem of stopping the unwinder crashing was to simply ask the > address space manager whether the stack frame we were about to > try and read existed and was readable. That should be completely > bulletproof, but I was worried about the cost as that was done > for every stack entry not just once per unwind.
The business of tracking the bounds of each stack is a pain, and makes for fragility -- for example, does it now work correctly with user-defined stacks? On consideration, your original solution seems preferable as it sidesteps all the stack bounds stuff. I wonder if the performance hit could be ameliorated by (1) adding a new function (in m_aspace's interface) to ask "is the page containing a given address mapped and readable, and (2) cacheing the results of such queries (inside m_aspacem) Clearly the cache would have to be flushed each time the mapping state changed, or at least partially flushed. However, unwind intensive code would likely do a lot of snapshots relative to map state changes, so the caching would be (temporally) effective. In addition, I'd bet that most stack frames are a lot smaller than a page, so the caching is also spatially effective: if we know that this frame is safe to poke around in, then it's likely that the next frame is in the same page and so we don't even need to ask aspacem about its safety. What do you reckon? Availability of a low-overhead page-safety check facility would be more generally useful too. For example in various syscall handlers we need to poke at the client supplied args and we're never 100% it won't fault, especially if the client is passing bogus pointers to the kernel. J ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Valgrind-developers mailing list Valgrind-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-developers
