RE: [Valgrind-users] not understanding some valgrind errors against afs...

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

Quoting Nicholas Nethercote <nj...@ca...>:

> On Tue, 15 Apr 2003, Neulinger, Nathan wrote:
> 
> > I think (from what I understand) that the problem is that if you
> lower
> > the threshold to something like 128K, valgrind will get confused if
> you
> > allocate a 128K+ object on the stack. If you're certain that no
> > individual object on the stack would be that size, it would probably
> be
> > useful to have an option to specify it.
> 
> Would a client request be a good compromise?  Eg.  insert
> VALGRIND_STACK_SWITCH just before the stack switch?  It's more
> intrusive
> than a command line option, but it's more precise.  Similar to the
> client
> request for handling self-modifying code.
> 
> [I haven't thought through how the request would actually be
> implemented,
>  but it shouldn't be too hard, I think...]

Yeah, it would.  It would need to mean something like "the next change to %esp is 
a stack switch", but what if changing the stack changes %esp multiple times?  How 
do you know if the compiler is going to generate some non-stack switch changes to 
%esp as part of its codegen?

I think the correct solution is to move stack switch detection into the skin 
themselves (memcheck, addrcheck and helgrind are the only ones I know of which 
care).  Memcheck and addrcheck can use their existing validity info to make the 
determination; helgrind is harder.

	J