Re: [PATCH][Revised] Add libgcc/config/t-emutls for darwin

[Jack Howarth <howarth at bromo dot med dot uc dot edu>]

On Sun, Mar 28, 2010 at 06:27:19PM +0100, IainS wrote:
>
> On 28 Mar 2010, at 06:52, Jack Howarth wrote:
>
>> libgcc_ext. This is because the build of libgcc on darwin is only
>> passed -DHAVE_CC_TLS but not -DUSE_TLS (appropriately since darwin
>> doesn't have assembler support for TLS but must use EMUTLS instead).
>
> I remain concerned that we have a configuration issue -- shouldn't we be 
> discovering that we have EMULTLS anyway?
>
> Also I repeat that, whilst it is true that:
>
> ===
>
> dnl Check whether the target assembler supports TLS.
> AC_DEFUN([GCC_CHECK_CC_TLS], [
>  GCC_ENABLE(tls, yes, [], [Use thread-local storage])
>  AC_CACHE_CHECK([whether the target assembler supports thread-local  
> storage],
>                 gcc_cv_have_cc_tls, [
>    AC_COMPILE_IFELSE([__thread int a; int b; int main() { return a = b; 
> }],
>      [gcc_cv_have_cc_tls=yes], [gcc_cv_have_cc_tls=no])]
>    )])
>  if test "$enable_tls $gcc_cv_have_cc_tls" = "yes yes"; then
>    AC_DEFINE(HAVE_CC_TLS, 1,
>              [Define to 1 if the target assembler supports thread-local 
> storage.])
>  fi])
>
> ===
>
> succeeds for the case that the assembler supports TLS...
> ....
>  AFAICT it also succeeds for EMULTLS.
>
> Therefore, either:
>  we have a config. problem
>
> or the macro comment should be:
>
>    "AC_DEFINE(HAVE_CC_TLS, 1,
>              [Define to 1 if the target supports thread-local  
> storage.])"
>
> Iain

Iain,
   My view is that either a different testcase needs to be found
for tls.m4 which can distinguish between assembler TLS support
and compiler based emutls support or the current code adapted
to handle both cases. Simply passing -DHAVE_CC_TLS without the
additional -DUSE_EMUTLS is clearly wrong and can result in 
unresolved symbols as I have demonstrated with the proposed
race condition patch.
               Jack