Re: [Valgrind-users] Valgrind, alloca(), and setjmp/longjmp

[Avery P. <ape...@ni...>]

On Mon, Nov 03, 2003 at 12:50:40PM +0100, Peter Firefly Lund wrote:

> On Sun, 2 Nov 2003, Avery Pennarun wrote:
> 
> > 	int x;
> 
> shouldn't x be volatile in any case?
> 
> (otherwise it might be stored in a register at setjmp/longjmp time -- and
> they are not required to save/restore registers so when another task
> longjmps back to your setjmp x will be trashed)

I'm willing to be proven wrong, but my understanding is that setjmp and
longjmp are allowed to trash any registers that any other function call is
allowed to trash - no more, no less.  Therefore, the compiler should do the
right thing even if x isn't volatile.

> > 	if (!setjmp)
> > 		longjmp(elsewhere)
> > 	// else someone longjmped back to me
> > 	VALGRIND_MAKE_READABLE(blah blah)
> > 	printf("x is now %d\n", x);
> 
> What you would really like is to save/restore the validity bits for a
> whole memory range together with your setjmp/longjmp.  A stack of validity
> stored bits won't be enough - you'll either need access to some id for
> each range (and have valgrind manage the memory) or you'll need some sort
> of escape hatch to copy these bits between valgrind and your memory space.

Not really - imagine if I do

	int x;
	obj->set_xptr(&x);
	if (!setjmp)
		longjmp(someone who sets x);
	// else someone longjmped back to me
	printf("x is now %d\n", x);
	
I expect the flags for 'x' to not be wiped by longjmp *and* to be different
upon return than they were when I left.  Suspending the auto-flag-changes
temporarily, then resuming them, would do this.

Revalidating the entire stack will also work, and that's what I'm doing
right now, but it loses some of valgrind's protection.

Have fun,

Avery