|
From: Bart V. A. <bar...@gm...> - 2006-09-17 13:03:50
|
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} ?
>
|