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
