llvm / clang and thread_local storage problems

[Jack Howarth]

On Sun, Oct 9, 2016 at 6:02 PM, Jack Howarth
<howarth.at.macports at gmail.com> wrote:
> On Sun, Oct 9, 2016 at 5:57 PM, Jack Howarth
> <howarth.at.macports at gmail.com> wrote:
>> On Sun, Oct 9, 2016 at 4:46 PM, Jack Howarth
>> <howarth.at.macports at gmail.com> wrote:
>>> On Sun, Oct 9, 2016 at 3:20 PM, Jeremy Huddleston Sequoia
>>> <jeremyhu at apple.com> wrote:
>>>>
>>>>> On Oct 9, 2016, at 09:47, Jack Howarth <howarth.at.macports at gmail.com> wrote:
>>>>>
>>>>> On Sun, Oct 9, 2016 at 3:53 AM, Jeremy Huddleston Sequoia
>>>>> <jeremyhu at apple.com> wrote:
>>>>>> thread_local support was added in OS X 10.9 (along with __cxa_thread_atexit being added to Libc as part of that support).  As long as your minimum deployment target is 10.9, you should be fine.  The issue is that you're on 10.6, so you don't have __cxa_thread_atexit.
>>>>>>
>>>>>> There is active conversation right now about adding a fallback implementation of __cxa_thread_atexit directly into libcxxabi.  See https://reviews.llvm.org/D21803 as that might be quite useful for your needs.  If so, provide a patch to libcxxabi that incorporates it, and I'll get it in.
>>>>>
>>>>> On the topic of thread local support, the failures in the guile 2.0.x
>>>>> test suite should be looked at...
>>>>>
>>>>> https://trac.macports.org/ticket/52556
>>>>>
>>>>> to determine if Apple's thread-local-storage implementation is buggy
>>>>> as upstream guile claims.
>>>>
>>>> Radar?
>>>
>>> radar://28688091 "guile 2.0.12 exposes potential thread-local-storage
>>> bug on Mac OS X"
>>
>> One other piece of information is the following comments placed in
>> libguile/threads.c that should give you a rough picture of what guile
>> is doing with thread-local-storage (in case anything there seems
>> outside the scope of the Apple implementation).
>>
>> /* When thread-local storage (TLS) is available, a pointer to the
>>    current-thread object is kept in TLS.  Note that storing the thread-object
>>    itself in TLS (rather than a pointer to some malloc'd memory) is not
>>    possible since thread objects may live longer than the actual thread they
>>    represent.  */
>>
>> /* Cache the current thread in TLS for faster lookup.  */
>>
>
> One other comment in libguile/async.c
>
> /* These are function variants of the same-named macros (uppercase) for use
>    outside of libguile.  This is so that `SCM_I_CURRENT_THREAD', which may
>    reside in TLS, is not accessed from outside of libguile.  It thus allows
>    libguile to be built with the "local-dynamic" TLS model.  */
>

FYI, rebuilding guile-2.0.12 with -ftls-model=local-dynamic passed on
CPPFLAGS doesn't suppress the regressions.

>>>
>>> Note that currently the guile Portfile in MacPorts lacks the support
>>> for 'sudo port -d test guile' to work.
>>>
>>>>