|
From: Konstantin S. <kon...@gm...> - 2007-11-01 13:26:31
|
Hi Julian,
What shall I do if my .so has no soname?
What if my locking primitives reside in the main binary?
Thanks,
--kcc
On 10/31/07, Julian Seward <js...@ac...> wrote:
>
> On Wednesday 31 October 2007 16:01, Konstantin Serebryany wrote:
> > Hi,
> >
> > I am trying to use thrcheck from THRCHECK branch.
> >
> > My program uses pthread_create to create threads, however it does not
> use
> > pthread_mutex_lock/unclock for locking -- it has its own set of locking
> > primitives.
> >
> > Is it possible to enhance thrcheck to handle user-settable lock/unlock
> > primitives?
>
> Yes, it is already possible. Look in tc_intercepts.c
> and look at the functions pthreadZumutexZulock and
> pthreadZumutexZuunlock. You need to make something like these
> (add them to tc_intercepts.c to keep your life simple).
>
> In the lock wrapper, the important components are
>
> VALGRIND_GET_ORIG_FN(fn);
>
> CALL_FN_W_W(ret, fn, mutex);
>
> if (ret == 0 /*success*/) {
> DO_CREQ_v_W(_VG_USERREQ__TC_PTHREAD_MUTEX_LOCK_POST,
> pthread_mutex_t*,mutex);
>
> It is this last part that notifies the tool that you acquired
> the lock.
>
> In the unlock wrapper, the important components are
>
> VALGRIND_GET_ORIG_FN(fn);
>
> DO_CREQ_v_W(_VG_USERREQ__TC_PTHREAD_MUTEX_UNLOCK_PRE,
> pthread_mutex_t*,mutex);
>
> CALL_FN_W_W(ret, fn, mutex);
>
> So in the lock wrapper you don't notify Thrcheck you have the lock
> until after the CALL_FN_W_W (the real lock call) succeeds.
> Conversely in the unlock wrapper you tell thrcheck you have
> released the lock before you really have released it.
>
> You will need to know the soname of the object containing your
> lock/unlock functions in order that you can write the magic PTH_FUNC
> wrapper. Study PTH_FUNC and QT4_FUNC. You can find the soname of
> xyz.so by doing "readelf -a xyz.so | grep soname".
>
> Use --trace-redir=yes and/or -v to find out whether your wrappers
> are actually getting called or not.
>
> J
>
|