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

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

On Fri, 2004-01-23 at 10:17, Nicholas Nethercote wrote:
> Would it be possible to do it another way -- keep Valgrind running, but
> pass through the original code untouched?  You could still put it in the
> translation table/cache, etc.  Or does the code get fiddled enough by V to
> make this difficult?

Well, yes, that's what happens now, in a sense.  --stop-after doesn't
make Valgrind evaporate, it just directly calls into the client code and
sets it going.

The trouble is that all the places in which V would normally interpose
itself will be unintercepted, so V can't do anything useful.  This would
affect:
      * stack growth - V normally catches SIGSEGV and grows the stack if
        appropriate.  We could leave a SIGSEGV handler in place to deal
        with this, but if the client changes it, it loses
      * signal syscalls - V normally does something special for all of
        these, but they'll go straight to the kernel when running native
        code
      * threads - only the thread which happened to be running at
        --stop-after will continue running; all the rest will be in
        suspended animation
      * client callbacks - anything the client was relying on client
        callbacks for (most of libpthread, malloc, etc) will stop
        working.  Malloc is likely to be the most troublesome

So, if your client is single threaded, you aren't using a
malloc-intercepting tool, and the client doesn't want to grow its stack,
then it might be possible to keep running.  With a fair amount of
engineering effort and complexity we can probably do better than this,
but it doesn't seem worth it.

	J