On Tue, 2014-08-19 at 21:44 +0200, David Faure wrote:
> On Tuesday 19 August 2014 21:00:58 Philippe Waroquiers wrote:
> > On Tue, 2014-08-19 at 16:46 +0200, Roland Mainz wrote:
> > > > ThreadSanitizer won't comprehend the fence instructions inserted by
> > > > urcu.
> > > > I believe even Helgrind won't, because these instructions do not imply
> > > > any happens-before relation.
> > >
> > > Is there any opensource or commercial tool which might help in such
> > > situations (e.g. problems with memory barriers) ?
> >
> > helgrind or drd or ThreadSanitizer could still be used for race
> > condition detection but you would have to annotate either the rcu
> > library or the calling code to describe the happens before
> > relationships.
>
> Are such annotations documented somewhere?
http://www.valgrind.org/docs/manual/hg-manual.html#hg-manual.client-requests
gives a list of such annotations, and points to helgrind.h for more
information.
> I'm still trying to find a way to annotate threadsafe-statics so that
> helgrind
> doesn't complain about them.
What is a threadsafe-static ?
Is that using __thread in something like:
void fun(void)
{
static __thread int no_race_on_this_var_is_possible;
....
}
If that is the case, I am just finishing a change that should avoid
false positive in __thread variables.
Humph, replace rather 'change' by kludge:
The user will have to add the option
--sim-hints=no-nptl-pthread-stackcache
and that uses a nasty kludge to disable the nptl pthread stack&tls
cache, as helgrind does not understand that the memory for e.g.
tls __thread variables is "safely" re-usable by another thread once the
thread is finished.
Philippe
------------------------------------------------------------------------------
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
