-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Memory managers should deregister EH frames in their destructor. #24365
Comments
Hi Tom, Belatedly looking in to this: This patch can no longer be applied as-is, because ObjectLinkingLayer no longer keeps its RuntimeDyld instance around. The RuntimeDyld instance is now used temporarily to allocate and fix up the object object file then discarded. The ConcreteLinkedObjectSet only holds on to the MemoryManager instance. The right solution in the short term is to have your MemoryManager implementation deregister the EH frames from its destructor. In the long term we should change the MemoryManager instance to clarify that it owns the registered frames, and we should kill off the deregisterEHFrames method on the interface entirely.
|
Hi Lang, Yes, the patch was created some time ago against an older version of the llvm sources. I assume the long term solution will be to make the memory managers base class 'RuntimeDyld::MemoryManager' the owner of the registered EH frames, and make it's destructor deregister the frames? Regards, |
Updating the title of this radar in light of earlier discussion: The right thing to do is for memory managers to deregister the frames themselves. |
Is this still the plan? RTDyldMemoryManager doesn't do it today: https://github.com/llvm/llvm-project/blob/31ca49be/llvm/lib/ExecutionEngine/RuntimeDyld/RTDyldMemoryManager.cpp#L32 Will EH frame handling in JITLink be analogue to RuntimeDyld? |
Hi Tom, Stefan, A very belated update on this. I believe it should have been fixed for ORC by r302589 / c936ac7. EH-frame deregistration in MCJIT is still manual for backwards compatibility.
No: JITLink handles all of this differently. JITLink's memory managers are responsible for memory management (and permission setting) only. EH-frame registration/de-registration is handled by a plugin, and plugins are always destroyed before the memory manager so these kinds of bugs (either leaking registered frames, or deregistering them after freeing the underlying memory) should not be possible. -- Lang. |
Extended Description
llvm::Orc::ObjectLinkingLayer should deregister EH Frames when an objectSet is removed (removeObjectSet) or when it is destructed (~ObjectLinkingLayer)
The text was updated successfully, but these errors were encountered: