[PATCH] D36078: [XRay][compiler-rt] Remove use of std::mutex and std::shared_ptr from global scope.

[Dean Michael Berris via llvm-commits]

> On 2 Aug 2017, at 00:54, David Blaikie <dblaikie at gmail.com> wrote:
> 
> 
> 
> On Tue, Aug 1, 2017 at 7:52 AM Dean Michael Berris <dberris at google.com <mailto:dberris at google.com>> wrote:
>> On 2 Aug 2017, at 00:49, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote:
>> 
>> 
>> 
>> On Mon, Jul 31, 2017 at 11:18 PM Dean Michael Berris via Phabricator <reviews at reviews.llvm.org <mailto:reviews at reviews.llvm.org>> wrote:
>> dberris added a comment.
>> 
>> In https://reviews.llvm.org/D36078#826962 <https://reviews.llvm.org/D36078#826962>, @kpw wrote:
>> 
>> > What's the primary motivation? Are we trying to avoid the upfront cost of global initialization? The unspecified destructor ordering with multithreaded programs?
>> 
>> 
>> The primary motivation is to avoid the initialization of atomics at initialization time. This has caused some issues in the past with dynamic linking and relocations.
>> 
>> Correctness issues? Performance issues? Seems like it'd be good to have the issues described more fully here (and/or in the commit(s) for posterity/clarity)
>>  
> 
> Runtime crashes during initialisation and incompatibilities. I guess you can call those correctness issues.
> 
> Is there more detail that could be documented here - basically a full answer to "why can't xray (or compiler-rt in general?) have global initializers?" (if this is a compiler-rt requirement maybe it should be written down somewhere more centrally, if it's only an xray requirement, at least documenting it fully in the commit messages and maybe in some comments could be good)

I'm not sure if it's a specific requirement in compiler-rt, but it sounds like a good thing to do for later.

For the "why can't we have global initialisers" -- it's not exactly "can't", more like, "shouldn't".

In some esoteric/special cases, where code running before the dynamic linker (or while the dynamic linker is running), having variables that need to be atomically initialised that calls a function accessed through an indirect call (through the PLT or something similar) can cause dependency issues -- and sometimes some crashes. We can't guarantee that the order of linking and code running in .preinit_array will run before the dynamic relocations have finished (as far as I can tell).

Having no global initializers (or at least ones that are trivial) avoids these observed problems.

> 
> I'd be curious (& I think it'd be good to write down) to better understand the mechanism of action - how does a global initializer lead to a crash in this instance & what's incompatible/why?
> 

I would like to be able to do that exactly too, but I only have anecdotes to show that having no global initialisers limits the number of weird issues encountered with regards to initialisation order and potential for being in an uninitialised state depending on how the binary is linked. Especially with the XRay runtime. I'm not too sure this is a problem with the other sanitisers, but XRay is enough different that the requirements might be very different from say, asan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170802/6e16044b/attachment.html>