[PATCH]Unload EH frames in ~MCJIT

[Kaylor, Andrew]

Hi Yaron,

This looks pretty good.  I have a couple of minor clean up issues, but I can clean it up and commit if you like.

I think you're right that eventually it might be nice to have a module to section mapping somewhere so that individual modules can be unloaded, but there are a lot of other issues that would need to be resolved to make that happen, so I think it's OK just to defer that problem for now.

I believe that RuntimeDyldImpl::emitSection is probably the best place to add the extra zeroes at the end of the .eh_frame section.  That's where we allocate memory for the section and copy the code-gen'd bits into the dynamic memory block.  I'll try to add that before committing.

-Andy

From: Yaron Keren [mailto:yaron.keren at gmail.com]
Sent: Monday, October 14, 2013 9:46 PM
To: Kaylor, Andrew; llvm-commits at cs.uiuc.edu
Subject: Re: [PATCH]Unload EH frames in ~MCJIT

Hi Andy,

I have updated the patch to latest SVN with your multi-module patch, attached.

These are the issues fixed in this patch:

1) Dynamic load of __register_frame and __deregister_frame at runtime. This makes EH work in cross-compilation where these functions are not available at compile time but are available at runtime. Including (but not limited to) to building clang with Visual C++ and running with MingW headers and runtime which is the configuration I'm using now.

2) deregisterEHFrames() in all relevant places finally calling __register_frame(). I have implemented a separate function per your suggestion, it does cause some code duplication.

3) ~MCJIT() calling Dyld.deregisterEHFrames();.

4) Call __registerframe once only in non-Apple platforms. According to

http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/061768.html

this is the right thing to do. I have tested this change on Windows only where it indeed makes exceptions work right.

These are the issues not yet fixed:

5) As you write, (de)registerEHFrames() should be done per-module but we do not keep the module-specific EH information. Maybe RuntimeDyldELF should keep a map of (modules, EH frames) so we can load and unload EH for specific module ?

6) The four final zero bytes in .eh_frame issue. Currently (in Windows) it works as there are zeros following .eh_frame. I don't know if it's pure luck or some other frame following in memory with zeros but we need to make sure these four zeros are always there.

Where would be the right place to append these bytes between the creation of .eh_frame (without zeros) and the usage of .eh_frame in __register_frame requiring zeros)?
Maybe in RuntimeDyldELF::finalizeLoad()?

Yaron



2013/10/9 Kaylor, Andrew <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>>
Hi Yaron,

I'm in the process of updating the EH frame support in MCJIT and RuntimeDyld to handle registration of multiple generated or loaded objects.  These changes involve an update to the memory manager and RuntimeDyld interfaces for registering EH frame data.  They will also highlight complications which would need to be considered in your patch with regard to deregistration of frame data.

In addition, I would prefer to have a separate "deregister" function rather than overloading the behavior of the registerFrames function.

I'm attaching my current patch so you can see where this is going.  Also feel free to provide feedback on the patch.

Please wait for my multiple object patch to be committed.  After that we can discuss the details of how deregistration should work.

Thanks,
Andy


From: llvm-commits-bounces at cs.uiuc.edu<mailto:llvm-commits-bounces at cs.uiuc.edu> [mailto:llvm-commits-bounces at cs.uiuc.edu<mailto:llvm-commits-bounces at cs.uiuc.edu>] On Behalf Of Yaron Keren
Sent: Wednesday, October 09, 2013 10:22 AM
To: llvm-commits at cs.uiuc.edu<mailto:llvm-commits at cs.uiuc.edu>
Subject: [PATCH]Unload EH frames in ~MCJIT

Module loaded with MCJIT register its EH frames with __register_frame to the runtime library. After MCJIT destructs and the module unloaded,  the runtime stays with invalid frames of the module, leading to faulty EH behaviour next time.

This patch calls __deregister_frame upon MCJIT destruction to keep proper runtime library EH state.

Yaron


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