On 06/08/14 19:09, David Faure wrote:
> I'm using helgrind quite a lot these days, and I love it.
> 
> However I wonder if it doesn't give me false positives for the case of 
> reading 
> a value from a static object, which was set in the constructor.
> 
> Given that gcc does indeed implement "threadsafe statics" as per C++11 (but 
> even before C++11 came out), one can assume that gcc does "something like" a 
> mutex around the creation of the object, and therefore that there is a 
> "happens before" relation between the end of the constructor and the use of 
> this object later on, right?
> 
> In that case it would seem that helgrind needs to learn that, to avoid many 
> false positives.
> 
> Testcase attached.
> 
> The assembly code says
>         call    __cxa_guard_acquire
>         testl   %eax, %eax
>         je      .L3
>         .loc 1 16 0 discriminator 2
>         movl    $_ZZ11threadStartPvE9singleton, %edi
>         call    _ZN9SingletonC1Ev
>         movl    $_ZGVZ11threadStartPvE9singleton, %edi
>         call    __cxa_guard_release
> .L3:
> 
> IIRC __cxa_guard_acquire/release is the protection around the static, but I'm 
> not sure exactly what this means. Is there an actual happens-before relation 
> here?

I think g++ will have to be modified to allow Helgrind and DRD to
recognize thread-safe statics on architectures that do not have relaxed
memory consistency. From the gcc source file gcc/cp/decl.c I derived
that on architectures without relaxed memory consistency that g++
protects static initialization as follows:

           static <type> guard;
           if (!guard.first_byte) {
             if (__cxa_guard_acquire (&guard)) {
               bool flag = false;
               try {
                 // Do initialization.
                 flag = true; __cxa_guard_release (&guard);
                 // Register variable for destruction at end of program.
               } catch {
                 if (!flag) __cxa_guard_abort (&guard);
               }
           }

If g++ would be modified such that the "if (!guard.first_byte)" test can
be skipped at run-time then it would become possible for Helgrind and
DRD to recognize static initialization by intercepting the
__cxa_guard_*() functions. However, I'm not sure which mechanism the gcc
maintainers will prefer for disabling that if-test at run-time.

Bart.

------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://www.hpccsystems.com
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Reply via email to