[PATCH]Unload EH frames in ~MCJIT

[Yaron Keren]

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/20b73cd9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-ee.diff
Type: application/octet-stream
Size: 9290 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131015/20b73cd9/attachment.obj>