In message <[EMAIL PROTECTED]>
Julian Seward <[EMAIL PROTECTED]> wrote:
> 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?
Well it should do so long as they are registered with the
appropriate client request (oddly wine seems to register the
initial stack for each process but not those for any other
threads it creates).
> 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
Well it really needs to check a range of addresses - unwinding
a stack frame on x86 using the frame pointer requires reading
a group of 8 bytes, which can cross a page boundary.
> (2) cacheing the results of such queries (inside m_aspacem)
Interesting - using an oset or something presumably?
As Nick said, we may as well enter the entire segment into the
cache rather than just the one page - it will only be one cache
entry anyway and it is likely to cover the entire stack with a
single entry that way.
> 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.
Indeed.
> 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.
If we cache the entire segment that we get ever better spatial
effectiveness from the cache.
> 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.
Well the system call stuff could use VG_(am_is_valid_for_client) at
the moment, though that has to binary search all the current segments
every time.
Note that stack unwinding needs to allow reading of V segments as
well as C segments, as we are sometimes unwinding valgrind's stack
rather than the client's. The system call check will only want to
allow C segments.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
-------------------------------------------------------------------------
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
