|
From: Konstantin S. <kon...@gm...> - 2007-10-31 15:01:12
|
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? Do you have this in plans? If not, I could try it myself (with some minimal guidance :)) Thanks, --kcc |
|
From: Julian S. <js...@ac...> - 2007-10-31 16:11:20
|
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
|
|
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
>
|
|
From: Julian S. <js...@ac...> - 2007-11-01 13:41:26
|
On Thursday 01 November 2007 14:26, Konstantin Serebryany wrote:
> Hi Julian,
>
> What shall I do if my .so has no soname?
> What if my locking primitives reside in the main binary?
That's ok. Use "NONE". See readelf.c:904.
J
>
> 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
|
|
From: Konstantin S. <kon...@gm...> - 2007-11-02 08:39:20
|
It works, many thanks!
--kcc
On 11/1/07, Julian Seward <js...@ac...> wrote:
>
> On Thursday 01 November 2007 14:26, Konstantin Serebryany wrote:
> > Hi Julian,
> >
> > What shall I do if my .so has no soname?
> > What if my locking primitives reside in the main binary?
>
> That's ok. Use "NONE". See readelf.c:904.
>
> J
>
> >
> > 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
>
|