Re: __emutls_v.__gcov_indirect_call_counters and ___emutls_v.__gcov_indirect_call_callee

[Richard Guenther <rguenther at suse dot de>]

On Wed, 31 Mar 2010, Jack Howarth wrote:

> Richard,
>    I apologize for the mix up in testing the race
> condition patch for value profiling of the indirect
> calls on darwin. We may need to regress that out for
> gcc 4.5, but first I would like to try to get a PR
> opened to define the scope of the problem that it causes.
> In particular, it is very strange that darwin appears 
> to be the only target exhibiting failures in profiling 
> after the race condition patch was committed. On
> darwin this patch causes unresolved symbols...
> 
> /sw/src/fink.build/gcc45-4.4.999-20100330/darwin_objdir/gcc/xgcc
> -B/sw/src/fink.build/gcc45-4.4.999-20100330/darwin_objdir/gcc/
> /sw/src/fink.build/gcc45-4.4.999-20100330/gcc-4.5-20100330/gcc/testsuite/gcc.dg/matrix/transpose-1.c
>    -fprofile-generate -O3  -lm   -o
> /sw/src/fink.build/gcc45-4.4.999-20100330/darwin_objdir/gcc/testsuite/gcc/transpose-1.x01
> Undefined symbols:
>   "___emutls_v.__gcov_indirect_call_counters", referenced from:
>       _mem_init in cc591Wfh.o
>       _main in cc591Wfh.o
>       global constructors keyed to 65535_0_transpose_1.c in cc591Wfh.o
>   "___emutls_v.__gcov_indirect_call_callee", referenced from:
>       _mem_init in cc591Wfh.o
>       _mem_init in cc591Wfh.o
>       _main in cc591Wfh.o
>       _main in cc591Wfh.o
>       global constructors keyed to 65535_0_transpose_1.c in cc591Wfh.o
>       global constructors keyed to 65535_0_transpose_1.c in cc591Wfh.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> 
> Is darwin the only target that really uses emulated tls? I had assumed
> from...
> 
> case ${host} in
> i[34567]86-*-linux* | x86_64-*-linux* | \
>   i[34567]86-*-kfreebsd*-gnu | i[34567]86-*-knetbsd*-gnu | \
>   i[34567]86-*-gnu*)
>         tmake_file="${tmake_file} t-tls"
>         ;;
> esac
> 
> in libgcc/config.host that only those targets are actually using
> native tls in FSF gcc. Or are there actually different levels of
> emulated tls?
>    Who has the most expertise on the emulated tls code and could
> provide some insight on this issue? There is some concern that
> the emulated tls code might not be functioning entirely as expected
> on darwin (despite the absence of testsuite failures without the
> race condition patch). Thanks in advance for any suggestions.
>                     Jack
> ps We certainly have the emutls symbols in gcc trunk in general.
> Current trunk shows...
> 
> [MacPro:darwin_objdir/x86_64-apple-darwin10.3.0/libgcc] howarth% nm
> libgcc_s.1.dylib | grep emutls
> 00013e70 T ___emutls_get_address
> 00014070 T ___emutls_register_common
> 00013e20 t _emutls_destroy
> 00013de0 t _emutls_init
> 00015100 b _emutls_key
> 000150a0 d _emutls_mutex
> 000150fc b _emutls_size
> 
> [MacPro:darwin_objdir/x86_64-apple-darwin10.3.0/libgcc] howarth% nm
> libgcc_ext.10.5.dylib | grep emutls
> 00013e70 T ___emutls_get_address
> 00014070 T ___emutls_register_common

I suppose they are not exported.

Richard.