Re: [Valgrind-developers] Re: Making Valgrind Core Framework multithread-safe?

[Josef W. <Jos...@gm...>]

On Tuesday 03 June 2003 11:10, Adam Gundy wrote:
> At 20:19 02/06/2003 +0200, Josef Weidendorfer wrote:
> >So what about a buffer, splitted in two parts with a wait condition for
> > each part, meaning "buffer part full". So if half of the ring buffer gets
> > full, the handler process is notified. And make a timeout in the handler
> > to check regularily for data (when little event data will be produced).
>
> sounds like a serial port fifo.... (eg a 16550 where you have a 16 byte
> buffer, and you can set the level at which an interrupt is generated.
> depending on how quickly you can clear the buffer you set it to 8, 12 etc,
> so there is still some buffer space to be filled while the interrupt is
> being serviced).
>
> a direct analogy of this would be eg a 16Mb buffer, then valgrind sends a
> real-time 'empty the buffer' signal to the worker process when it is 8Mb
> full etc. the idea is that valgrind would automatically adjust to the speed
> of signal delivery etc by altering the point at which it decides a signal
> needs to be sent.

Good idea.

> >> >> sounds good for cache simulation, since the events are one way only -
> >> >> I doubt it would be useful for memcheck though - the number of error
> >> >> events (should be) tiny.
> >> >
> >> >Couldn't be all the shadow memory stuff be done in the event handler
> >> > process? Perhaps this split is even worth it only to allow for easier
> >> > development/bug fixing/valgrinding of the memcheck event handler
> >> > functions themself, and the normal case would be to run them in the V
> >> > process again?
> >> >(Perhaps this is nonsense, as I don't know enough about memcheck).
> >>
> >> writes but not reads... memcheck is constantly checking the shadow
> >> memory state as well as updating it.
> >
> >Yup.
> >On reads, an error to be reported could happen. But why has Valgrind core
> > to stop, and wait to see if a read will give you an error? The error
> > should be printed by the handler. Perhaps a problem would be that the
> > handler has to track the stack frames for the backtrace in the error
> > message.
> >Ok, you can't attach a debugger when the error happens :-(
>
> you would have to send a stack trace with every memory test - this would be
> horribly slow. hmmm. I guess delta compression of the stack trace would
> help, since typically only the top frame changes... you would also need
> some sort of optimized stack trace maintained for each thread as well -
> track calls and returns, so that most of the time you only need to look at
> EIP to get the current stack trace. there are some odd cases where RET is
> not used which would cause pain.

Luckily, this work is already done.
In my calltree skin, I track the call chain on my own for each thread, using 
CALL/RET/JUMP events with the content of %esp. It handles situations like 
longjmp and exception handling quite fine.

Josef