LUMIERA.clone/research/clang-static-init-1.cpp


#include "clang-static-init.hpp"


int
main (int, char**)
  {
    cout <<  "\nStart Testcase: invoking two instances of the configurable singleton factory...\n";
    
    test::Subject& ref1 = test::fab.get();
    test::Subject& sub2 = test::fabricate();
    
    cout << "sub1="<< &ref1 << " sub2="<< &sub2 <<"\n";
    
    
    return 0;
  }
bughunt: extract a call sequence leading to a strange init error with Clang Observations: - the initial observation was that we get two instances of the config rules service - obviously this it is not the initialisation of a static variable accessed from multiple compilation units. But the access from two compilation units is crucial - we can exclude the effect of all other initialisation. It is in SingletonSubclass - we can exclude the effect of dynamic linking. Even two translation units linked statically exhibit the same problem rebuild this test case in the research area, to be able to verify with various compilers 2013-09-29 01:08:15 +02:00
bughunt: build testcase statically linked ...but still dynamically linking against the core lib But the actual template instantiations happen now within the two compilation units, which are linked statically. When looking into the symbol table, we can see that the static field is emitted two times readelf -W target/clang-static-init -s \| c++filt \|less 2013-09-30 00:42:27 +02:00			`#include "clang-static-init.hpp"`
bughunt: extract a call sequence leading to a strange init error with Clang Observations: - the initial observation was that we get two instances of the config rules service - obviously this it is not the initialisation of a static variable accessed from multiple compilation units. But the access from two compilation units is crucial - we can exclude the effect of all other initialisation. It is in SingletonSubclass - we can exclude the effect of dynamic linking. Even two translation units linked statically exhibit the same problem rebuild this test case in the research area, to be able to verify with various compilers 2013-09-29 01:08:15 +02:00


bughunt: build testcase statically linked ...but still dynamically linking against the core lib But the actual template instantiations happen now within the two compilation units, which are linked statically. When looking into the symbol table, we can see that the static field is emitted two times readelf -W target/clang-static-init -s \| c++filt \|less 2013-09-30 00:42:27 +02:00			`int`
			`main (int, char**)`
			`{`
bughunt: re-create the whole 2nd layer with a configurable product type --> HIT Now we've reprduced the problematic situation in isolation 2013-10-06 18:50:53 +02:00			`cout << "\nStart Testcase: invoking two instances of the configurable singleton factory...\n";`
bughunt: build testcase statically linked ...but still dynamically linking against the core lib But the actual template instantiations happen now within the two compilation units, which are linked statically. When looking into the symbol table, we can see that the static field is emitted two times readelf -W target/clang-static-init -s \| c++filt \|less 2013-09-30 00:42:27 +02:00
bughunt: re-create the whole 2nd layer with a configurable product type --> HIT Now we've reprduced the problematic situation in isolation 2013-10-06 18:50:53 +02:00			`test::Subject& ref1 = test::fab.get();`
			`test::Subject& sub2 = test::fabricate();`
bughunt: build testcase statically linked ...but still dynamically linking against the core lib But the actual template instantiations happen now within the two compilation units, which are linked statically. When looking into the symbol table, we can see that the static field is emitted two times readelf -W target/clang-static-init -s \| c++filt \|less 2013-09-30 00:42:27 +02:00
			`cout << "sub1="<< &ref1 << " sub2="<< &sub2 <<"\n";`


			`return 0;`
			`}`