Skip to content
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

Closed
llvmbot opened this issue Jun 30, 2015 · 5 comments
Closed

Memory managers should deregister EH frames in their destructor. #24365

llvmbot opened this issue Jun 30, 2015 · 5 comments
Labels
bugzilla Issues migrated from bugzilla orcjit

Comments

@llvmbot
Copy link
Collaborator

llvmbot commented Jun 30, 2015

Bugzilla Link 23991
Resolution FIXED
Resolved on Dec 20, 2019 01:36
Version trunk
OS Linux
Attachments proposed patch
Reporter LLVM Bugzilla Contributor
CC @lhames,@weliveindetail

Extended Description

llvm::Orc::ObjectLinkingLayer should deregister EH Frames when an objectSet is removed (removeObjectSet) or when it is destructed (~ObjectLinkingLayer)

@lhames
Copy link
Contributor

lhames commented May 3, 2016

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.

  • Lang.

@llvmbot
Copy link
Collaborator Author

llvmbot commented May 17, 2016

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,
Tom

@lhames
Copy link
Contributor

lhames commented May 24, 2016

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.

@weliveindetail
Copy link
Contributor

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?

@lhames
Copy link
Contributor

lhames commented Dec 20, 2019

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.

Will EH frame handling in JITLink be analogue to RuntimeDyld?

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.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 10, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla orcjit
Projects
None yet
Development

No branches or pull requests

3 participants