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

Dean Michael Berris via llvm-dev llvm-dev at lists.llvm.org
Tue Mar 14 17:38:18 PDT 2017


> On 13 Mar 2017, at 20:06, David Chisnall <david.chisnall at cl.cam.ac.uk> wrote:
> 
> On 13 Mar 2017, at 04:39, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> 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.
> 
> thread_local depends on any runtime (ABI library) features for destruction, so it’s only a dependency if you have thread-local global with a non-trivial destructor.  Local static (non-thread-local) variables also depend on the ABI library for atomic creation.
> 

We use at-thread-exit thread_local variables at global scope to do cleanup for "at end of thread" functionality. So this means we do need some runtime support for that.

> These are less of an issue than standard library dependencies though, because these calls are all defined by the platform ABI and so if there are multiple options (libcxxrt, libsupc++, libc++abi) then you substitute any of them at run time.  This does mean that you’ll need to ensure that one of them is linked in the final binary though, and so must be overridden by the flag that selects C++ standard library implementation during linking.
> 

Fair enough. We already do some link-time flag selection in Clang for when you use it to link -fxray-instrument built/linked binaries.

We currently do not change the C++ library dependency though (nor force one).

Cheer

-- Dean

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


More information about the llvm-dev mailing list