This commit fixes an issue with deconstructing the SectionMemoryManager where the _vfptr on the MMapper instance variable would be wiped out by the time the ~SectionMemoryManager()
was called, thus causing a method call to _purecall() (MSVC specific) which then would trigger an abort()
This is most evident when running the LLVM Kaleidoscope example on windows.
Destructors of objects with static storage duration are called in reverse order of completion of their constructors or the completion of their dynamic initialization, and the functions passed to std::atexit are called in reverse order they are registered (last one first)
Previously, If a user created an object of static storage duration containing a SectionMemoryManager before the DefaultMMapperInstance was instantiated, this will cause an error. For example, consider the following construction order in a program
1.) static std::unique_ptr<KaleidoscopeJIT> (which holds an ObjectLayer which has a SectionMemoryManager)
Thus, at deconstruction time the order is
1.) DefaultMMapperInstance (This wipes out the Vtable)
2.) static std::unique_ptr<KaleidoscopeJIT> (which holds an ObjectLayer which has a SectionMemoryManager)
when the second destructor is called, it calls the virtual method on a wiped out table. Thus the explosion.
The solution here is to make SectionMemoryManager not rely on a static variable which can be wiped out before an instance of the class is ready to be destroyed, and thus ensuring each SectionMemoryManager has it's own reliable instance of DefaultMMapperInstance to be used at deconstruction time.
Note this bug error is specific to MSVC.
I have confirmed all tests pass on both Windows and Linux
Update: I have updated the diff to use ManagedStatic per recommendation and confirmed it fixes the issue