|
From: Julian S. <js...@ac...> - 2006-09-17 19:31:30
|
> Regarding option (2): would it be that hard to provide a macro or client
> request such that a function can be called from client code without
> triggering function wrapping ?
Doable on {x86,amd64,ppc32}-linux, but on ppc64-linux and also AIX, the need
to find the correct TOC pointers makes it (much) more complicated, ugly and,
ultimately, fragile. I thought about it more this afternoon. I have a
different proposal below.
> On Sunday 17 September 2006 19:41, Bart Van Assche wrote:
> Regarding the data structure for the ThreadId <> pthread_t mapping:
> - Maybe an array with ThreadId as index and pthread_t as value is
> sufficient as data structure. If C++ code was allowed in Valgrind, I would
> make it a datastructure of type std::map<pthread_t, ThreadId>.
Ok, so some kind of mapping from pthread_t to ThreadId anyway. Exactly
how it's implemented isn't a big deal.
> - Regarding locking from within vg_preloaded.c: equivalents for
> pthread_mutex_lock(), unlock(), init() and destroy() should be sufficient.
At least for locking, adding two client requests, test-and-set, and
yield-this-thread, would make it easy to implement locking completely
independently of the application's thread library. I volunteer to
hack it up for you.
> Please note that pthread_cond_init(), destroy(), signal() and wait() also
> should be made available in vg_preloaded.c -- see also the comment about
> busy waiting in the valgrind core patch for drd (
> http://home.scarlet.be/%7Ebvassche/drd/valgrind-6012-core-2006-08-27.patch)
Noted. What primitives do we need to implement condition variables?
I never really understood them.
J
|