|
From: Avery P. <ape...@ni...> - 2003-11-09 22:57:34
|
On Sun, Nov 09, 2003 at 05:11:08PM +0000, Nicholas Nethercote wrote:
> On Sun, 2 Nov 2003, Avery Pennarun wrote:
>
> > if (!setjmp)
> > VALGRIND_STOP_INVALIDATING
> > longjmp(elsewhere)
> > // else someone longjmped back to me
> > VALGRIND_START_INVALIDATING
> > printf("x is now %d\n", x);
>
> I don't think this feature is likely to be added, since it would
> only ever be used in extremely obscure circumstances, which is exactly the
> kind of feature we don't like adding. Sorry about that.
Yeah, I understand and agree with that philosophy myself, so I'll try to
keep my disappointment to a minimum. Anyway, lacking this feature only
results in false negatives (valgrind doesn't find certain unlikely kinds of
coding errors) so I'm pretty safe.
> (I still don't quite understand why you need to use this unusual
> setjmp/longjmp thing instead of switching stack in a more normal way,
> although I'm sure you have a good reason.)
Now you're just being mean. From coregeind_core.html:
* Programs which switch stacks are not well handled. Valgrind does have
support for this, but I don't have great faith in it. It's difficult --
there's no cast-iron way to decide whether a large change in %esp is as a
result of the program switching stacks, or merely allocating a large object
temporarily on the current stack -- yet Valgrind needs to handle the two
situations differently.
*My* way of switching stacks, on the other hand, should at least behave 100%
consistently in valgrind and I don't have to depend on anything except
VALGRIND_MAKE_READABLE working - because I'm not actually switching stacks,
I'm just moving the stack pointer around *inside* the stack in a
well-understood way.
I originally did this for portability (WvTask works in Turbo C++ for DOS as
well as Windows, Unix, and probably any other ANSI C system). Little did I
realize before how useful this portability would be when I started using
valgrind :)
Have fun,
Avery
|