[llvm-dev] Use of the C++ standard library in XRay compiler-rt

[Dean Michael Berris via llvm-dev]

> On 15 Mar 2017, at 11:38, Chandler Carruth <chandlerc at gmail.com> wrote:
> 
> On Tue, Mar 14, 2017 at 5:34 PM Dean Michael Berris via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> On 13 Mar 2017, at 15:39, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote:
> 
>> 
>> One thing we rely on heavily on in the FDR mode implementation is C++'s `thread_local` keyword. I'm not sure what that entails runtime-wise (does it need pthreads? or something else?) but I'm sure a functional replacement would be alright too.
>> 
>> No doubt we can find some common API for that, I'd guess tsan probably has already had to figure out things like that.
>> 
> 
> I suspect I'm more worried about costs rather than APIs. I've learned a while back that system-provided TLS functionality isn't as good as compiler-provided (and system/platform-specific) TLS implementations.
> 
> I think what you want here (see David Chisnall's post as well) is essentially the GNU extension '__thread' which both Clang and GCC have strong support for.
> 
> It works like thread_local except that it has the kind of restrictions David mentions so that it doesn't become a runtime burden.
> 
> (Note that thread_local, if it can at all require dynamic initialization, ends up quite bad even when the constructor is "trivial". sadly....)


Thanks Chandler! I'll look into __thread.

We're probably going to have to change the way we do "at thread-exit" handlers too if we can't just use thread_local on global objects with nontrivial destructors.

Cheers

-- Dean

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170315/67feefd8/attachment.html>