On Wed, Mar 31, 2010 at 02:14:41PM +0200, Richard Guenther wrote:
> 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.
Richard,
Shouldn't these still show up in the output from...
nm libgcc_s.1.dylib | grep emutls
with a lower case symbol type? I am wondering if the call
is being generated in tree-profile.c but not the actual
subroutine in the libgcc build?
Jack
ps I have opened PR43602 for this issue.
