Re: [Valgrind-developers] Merging stage2.c and vg_main.c [was Re: tool-specific CLOs] (fwd)

[Julian S. <js...@ac...>]

On Friday 23 January 2004 18:07, Jeremy Fitzhardinge wrote:
> On Fri, 2004-01-23 at 09:20, Nicholas Nethercote wrote:
> > Which is bad news for detecting bugs in the JIT-compiler;  you can't do
> > the binary search technique for finding erroneous BBs.
> >
> > (Well, you probably can if your error and the manifestation of it are
> > close enough, but if it's a subtle error that doesn't manifest for a
> > while, it won't work.)
> >
> > Any way we can achieve the same effect?
>
> Well, it was always a fairly crippled mechanism, since it never worked
> with threaded programs, or if signals happened.

I think we should remove support for --stop-after.  It's a shame, but
I can't see how it can work any more.  Even before FV etc, having to reduce
reducing bug cases to non-threaded, non-signal handling versions 
was a serious limitation.  If/when vcpu gets redesigned, we'll have to
figure out some other way to track down bugs in it.

> I guess you could try to set up a limited environment which can coddle a
> bit more execution out of the client, but it might turn out to be a
> significant amount of work, which would be bad.

No ... that stuff is complex enough as it is, and complicating it just to
support a not-very-usable debugging mode isn't a good idea.

> I agree with you about the debugging, but I don't really see how to
> achieve it.

I think we're all in agreement.

J