This is an archive of the discontinued LLVM Phabricator instance.

Atoms generated by a pass should be owned by the generated file and not the pass itself.
AbandonedPublic

Authored by Jean-Daniel on Dec 18 2014, 4:45 AM.

Details

Reviewers
kledzik
Summary

Some Mach-O specific passes own a MachOFile member that is used to allocate the generated atoms. This is a fragile pattern as the generated atoms and references lifespan are tied to the pass lifespan and freed when the pass instance is destroyed.

While it is not an issue today as the PassManager is not destroy before we write the linked file, there is no guarantee it will always work.

Now that the File base class provide an allocator, we can use the processed file's allocator to generate new atoms.

Note: I have commit rights, so if that patch is good, I'll be glad to commit it myself ;-)

Diff Detail

Repository
rL LLVM

Event Timeline

Jean-Daniel retitled this revision from to Atoms generated by a pass should be owned by the generated file and not the pass itself..
Jean-Daniel updated this object.
Jean-Daniel edited the test plan for this revision. (Show Details)
Jean-Daniel added a reviewer: kledzik.
Jean-Daniel set the repository for this revision to rL LLVM.
Jean-Daniel added a project: lld.
Jean-Daniel added a subscriber: Unknown Object (MLST).
kledzik edited edge metadata.Dec 18 2014, 9:38 AM

I see what you are trying to do, but it leaves the pass-generated atoms in an odd state. All the other atoms (from .o files) still have their file() method returning their original file. But the pass-generated atoms now have their file() return the temp mergedFile. When inspecting atoms in the Writer, it is nice to be able to see where they came from. This patch looses that.

Perhaps we can change Pass::perform() to return a std::unique_ptr<File> which is the owning file of any atoms generated during the pass. And the PassManager owns those Files even it it deletes the pass objects.

Also, I see this same pattern in other Passes. It is not mach-o specific.

OK, missed that side effect. Having the PassManager owning File will not solve the issue as the PassManager is not guarantee to live until we no longer need the mergedFile.

Anyway, after some though, this change is pointless as the actual pattern is consistent with the other linking steps (input graph, resolver, …). If somehow we need to be able to link a file in memory and keep the resulting representation, we will just make sure the PassManager and other objects live long enough.

Jean-Daniel abandoned this revision.Dec 18 2014, 10:38 AM