[PATCH]Unload EH frames in ~MCJIT

[Yaron Keren]

Hi Andy,

RuntimeDyldImpl::emitSection makes sense.

If I understand correctly, with the current implementation we can load
modules individually but must unload them all at once (when MCJIT is
killed).

Feel free to modify whatever needed and commit. Thanks!

Yaron



2013/10/15 Kaylor, Andrew <andrew.kaylor at intel.com>

>  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>****
>
>  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] *On Behalf Of *Yaron Keren
> *Sent:* Wednesday, October 09, 2013 10:22 AM
> *To:* 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/5ae6bd19/attachment.html>