|
From: Julian S. <js...@ac...> - 2006-09-17 13:52:34
|
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} ?
|