On Tue, 2014-08-19 at 22:29 +0200, Philippe Waroquiers wrote: > > It doesn't use __thread anywhere, but rather lets gcc take care of ensuring > > thread-safety on static objects (like C++11 mandates, but it has been doing > > so > > for a long time already). > Quickly re-reading the mail, this is not related. > I see that drd has some interceptions that does annotate > these like a mutex lock/unlock (see drd/drd_libstdcxx_intercepts.c) > and has a test which looks like your problem in > drd/tests/local_static.cpp > > I think a similar code is (trivially) doable for helgrind, > inside helgrind/hg_intercepts.c Just tried to do this trivial code. But I still had (what looks like) false positive. Probably explanation is that these drd intercepts are not working (yet), as documented in log for revision 14013: r14013 | bart | 2014-06-09 11:00:42 +0200 (Mon, 09 Jun 2014) | 1 line
drd/tests/local_static: Disable because g++ does not yet allow proper interception of initialization of local static variables I have no idea what problem/difficulty was encountered. What is exactly the semantic of a threadsafe static ? I understand it is initialised only once, and that such 'init once' is guaranteed thanks to __cxa_guard_acquire/__cxa_guard_release. However, what is __cxa_guard_abort used for ? Once the object is initialised, I guess it must be either used read-only by all threads, or have a classical way to be protected (e.g. via a mutex). Philippe ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
