[llvm] r227300 - [LPM] Rip all of ManagedStatic and ThreadLocal out of the pretty stack
resistor at mac.com
Wed Jan 28 16:53:08 PST 2015
> On Jan 28, 2015, at 3:05 PM, Chandler Carruth <chandlerc at gmail.com> wrote:
> On Wed, Jan 28, 2015 at 2:14 PM, Owen Anderson <resistor at mac.com <mailto:resistor at mac.com>> wrote:
> Hi Chandler,
>> On Jan 28, 2015, at 1:52 AM, Chandler Carruth <chandlerc at gmail.com <mailto:chandlerc at gmail.com>> wrote:
>> -static ManagedStatic<sys::ThreadLocal<const PrettyStackTraceEntry> > PrettyStackTraceHead;
>> +// We need a thread local pointer to manage the stack of our stack trace
>> +// objects, but we *really* cannot tolerate destructors running and do not want
>> +// to pay any overhead of synchronizing. As a consequence, we use a raw
>> +// thread-local variable. Some day, we should be able to use a limited subset
>> +// of C++11's thread_local, but compilers aren't up for it today.
>> +// FIXME: This should be moved to a Compiler.h abstraction.
>> +#ifdef _MSC_VER // MSVC supports this with a __declspec.
>> +static __declspec(thread) const PrettyStackTraceEntry
>> + *PrettyStackTraceHead = nullptr;
>> +#else // Clang, GCC, and all compatible compilers tend to use __thread.
>> +static __thread const PrettyStackTraceEntry *PrettyStackTraceHead = nullptr;
> Darwin doesn’t support __thread or thread_local on armv7 or arm64. This is breaking all Darwin embedded builds. :-(
> So, this is part of C++11 and threading... I don't know how to support a system which wants a threaded LLVM but doesn't support TLS. I'm happy to make these compile out when threading is disabled of course. Do you have any other suggestions?
Not particularly, other than restoring (part of?) the old behavior. Threaded LLVM is required by multiple users on embedded Darwin.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits