This is an archive of the discontinued LLVM Phabricator instance.

Initial Redirection Manager
AbandonedPublicDraft

Authored by sunho on Jul 18 2023, 12:52 AM.

Details

Reviewers
None

Diff Detail

Event Timeline

sunho created this revision.Jul 18 2023, 12:52 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 18 2023, 12:52 AM
Herald added a subscriber: hiraditya. · View Herald Transcript
lhames added a subscriber: lhames.Jul 18 2023, 8:32 PM

Very nice!

I really like your idea of breaking out the InProcessMemoryAccess class -- that's much more readable and reusable.

I think it would be good to break RedirectionManager up into the following hierarchy:

// Manages the process of redirection.
class RedirectionManager {
  virtual ~RedirectionManager() = default;

  virtual Error redirect(SymbolAddrMap NewDests) = 0;
};

// Manages redirectable symbols.
class RedirectableSymbolManager : public RedirectionManager {
public:
  virtual Error create(SymbolAddrMap InitialDests) = 0;
  virtual Error release(SymbolNameVector Syms) = 0;
};

Some clients only need to be able to redirect and don't need to know how to create new redirect able entry points. The distinction probably doesn't matter much initially, but naming them up-front may minimize renaming later, especially if/when we expose these through the C API.

These classes should get their own headers (RedirectionManager.h, RedirectableSymbolManager.h, JITLinkRedirecableSymbolManager.h). Lumping everything together in IndirectionUtils.h was a mistake (ditto in Core.h and ExecutionUtils.h) -- I want to slowly start to undo that and move to smaller headers as we deprecate older APIs.

We should probably make create take a ResourceTracker or JITDylib target to emphasize that a symbol is always defined inside some specific JITDylib (and is never just "free floating"). I wonder what the pros and cons of using ResourceTrackers for this rather than a remove API would be? I guess one really nice thing is that it plays well with the idiom "add this MaterializationUnit with functions renamed, plus these stubs pointing to the function bodies" -- you'd be able to add and remove both with one tracker.

llvm/include/llvm/ExecutionEngine/Orc/IndirectionUtils.h
334–337

This could be non-virtual -- I think it's fine for it to always be defined in terms of the multi-symbol version.

343–345

Similarly this could be non-virtual.

353–355

Here too.

llvm/lib/ExecutionEngine/Orc/IndirectionUtils.cpp
110

typo: redirectable

138–155

Maybe we should add a MemoryAccess::writePointer primitive?

sunho abandoned this revision.Aug 20 2023, 11:50 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 20 2023, 11:50 PM