[llvm] r190974 - Encapsulate PassManager debug flags to avoid static init and cxa_exit.

[Filip Pizlo]

On Sep 19, 2013, at 10:24 AM, Chandler Carruth <chandlerc at google.com> wrote:

> On Wed, Sep 18, 2013 at 9:03 PM, Andrew Trick <atrick at apple.com> wrote:
> 
> On Sep 18, 2013, at 5:51 PM, Chris Lattner <clattner at apple.com> wrote:
> 
>> On Sep 18, 2013, at 4:54 PM, Chandler Carruth <chandlerc at google.com> wrote:
>>> Andy, this really feels like a hack, and a bad hack at that.
>>> 
>>> Where is the requirement for the core library to have no static initializers coming from? What is the support plan here? What problem are you actually trying to fix?
>>> 
>>> Just for clarity, I have read the llvmdev thread, and I understand the *general* goal, but this patch itself doesn't seem like a clean incremental step toward that goal, doesn't reference any of the constructs under discussion in that thread.
>> 
>> I totally agree.  This seems like a hack that would be resolved by making cl::opt's get compiled out in non-assert builds, which you already described.
> 
> I'll coalesce my responses to Chris and Chandler here:
> 
> This fixes a particularly horrible bug where LLVM crashes during PassRegistry::removeRegistrationListener when a multi-threaded process exits while compiler threads are running.
> 
> OK, to make sure I understand correctly, this is the classical problem where threads are live at the moment exit is called, and thus global destructors are run out from under the threads?

Yes.

The PassOptionsList destructor is the one that happens to currently create the highest volume of such crashes.

-Filip


>  
> 
> This patch was meant to
> (a) fix a bug
> (b) handle one of the handful of special cl::opt cases that won't be covered by the general approach I outlined in the RFC.
> 
> The proposal talked about handling the majority of options incrementally without enormous churn. This case is an exception that I wanted to get out of the way first.
> 
> This case is special because we want the PassManager options to be availabe in non-assert builds, or so I thought. These are clearly "tool" options that need to be exported to a number of LLVM-based tools.
> 
> What about this patch is a hack, other than being a special case? Having tools call initializePassManager()? I can't think of any long-term solution where that can be avoided.
> 
> I thought this fix would be general all-around goodness, but I'd be happy to revert this patch and wrap the whole thing in #ifndef LLVM_NO_STATICINIT if Chris and Chandler prefer.
> 
> I'd like to first figure out what the end state actually looks like. Maybe that's better done on the original thread.
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130919/ee5258f0/attachment.html>