|
From: Bart V. A. <bar...@gm...> - 2006-09-17 18:41:27
|
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>. - Regarding locking from within vg_preloaded.c: equivalents for pthread_mutex_lock(), unlock(), init() and destroy() should be sufficient. 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). 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 ? On 9/17/06, Julian Seward <js...@ac...> wrote: > > > Re your (1) .. (3), these might work, but function wrapping is already > complicated and fragile, especially for platforms which use TOC pointers, > and I really don't want to mess with it. > > Supposing it was possible to implement a data structure for which updates > and queries are atomic. This is easily enough done by putting the > structure > and its access functions in the drd tool code and adding some client > requests to modify/query it. > > The question is, is that sufficient? Or do you really need to be able > to run arbitrary sections of locked code in the wrappers? > > Could you give a short summary of what the data structure requirements > are and what the locking requirements are [in the wrappers]. I don't > yet feel like I have a good enough picture of that. > > J > > > > On Sunday 17 September 2006 14:03, Bart Van Assche wrote: > > A client request for querying the Valgrind ThreadId from within the > client > > is not sufficient, it is also necessary to have locking primitives > > available that work from within vg_preloaded.so. There are several > possible > > solutions: (1) Change macro's like VALGRIND_GET_ORIG_FN such that these > > also return the original function address when one function defined in > > vg_preloaded.so calls another function defined in vg_preloaded.so. > > (2) Make it possible to disable function wrapping, such that who > implements > > functions in vg_preloaded.so has the option of either calling the > > non-wrapped or the wrapped function. > > (3) Directly call alternative locking functions from within > > vg_preloaded.so, such as sys_futex(). > > > > Option (3) would make porting drd hard: e.g. sys_futex() is available on > > Linux, but not on AIX. > > Option (1) is the most elegant, but I don't know whether it is possible > to > > implement. > > Option (2) has the disadvantage that data-race detection will have to be > > explicitly disabled for the data structures accessed from > vg_preloaded.so. > > > > On 9/14/06, Julian Seward <js...@ac...> wrote: > > > Sounds plausible, and I like the idea of not messing with the state > > > machine. So you are saying, if you had a client request > > > VG_USERREQ__GET_MY_THREADID, that is all you would need? > > > > > > How would you do the locking for this data structure? Would you > > > use pthread_mutex_{lock,unlock}? Does anything break if you call > > > those from inside the wrappers for pthread_{create,join} ? > |