[llvm-dev] ORC and MCJIT clients: Heads up, API breaking changes in the pipeline.

[Stefan Gränitz via llvm-dev]

Hi Lang, thanks for announcing. Would be great if you could send another
short notice as soon as the actual patch exists.
Best, Stefan

Am 24.05.16 um 23:06 schrieb Lang Hames via llvm-dev:
> Hi All,
>
> I'm going to be making some API breaking changes to the ORC APIs, and
> to the RuntimeDyld class (which underlies MCJIT). The changes may
> affect MCJIT clients but are unlikely to. Where they do the fixes are
> likely to be trivial. ORC clients will be affected, but the fixes
> should also be straightforward.
>
> I have three upcoming changes in mind:
>
> 1) RuntimeDyld (the linker underlying MCJIT and ORC) will now search
> for symbols using the SymbolResolver's findSymbolInLogicalDylib first,
> before falling back to the findSymbol method if
> findSymbolInLogicalDylib returns a null result.
>
> This is a step towards making RuntimeDyld behave more like a static
> linker: we prefer to link against symbols defined in the same "logical
> dylib" as the module being JIT'd, before linking against external symbols.
>
> For clients that have not implemented findSymbolInLogicalDylib (I
> suspect this covers most clients) this change will have no effect: the
> default version of findSymbolInLogicalDylib will be called and will
> return null, and RuntimeDyld will fall back to calling findSymbol as
> it did before.
>
> For clients that have implemented findSymbolInLogicalDylib: Beware
> that any symbol found via this call will now shadow symbols that might
> have been found via findSymbol. It is unlikely that anyone is relying
> on non-shadowing so I don't expect any trouble here, but if you do see
> any changes in symbol resolution after this change (which I expect to
> land today) this is something to have in mind.
>
> 2) MemoryManager deregisterEHFrames will be removed.
>
> Memory managers should own their registered EH frames and deregister
> them on destruction. This will bring EH frame ownership in line with
> memory ownership: memory managers are already responsible for freeing
> the memory that they've allocated when they are destructed.
>  
> To transition, clients should track the frames registered by their
> class, then deregister them in the destructor. For in-tree memory
> managers (and RuntimeDyld itself) this bug is being tracked
> by https://llvm.org/PR23991 .
>
> 3) Some operations in the ORC APIs, RuntimeDyld, SymbolResolver and
> MemoryManager will be modified to return Error/Expected.
>
> MCJIT and ORC both support remote execution of JIT'd code via RPC, but
> there is currently no way to cleanly bail out and report failure in
> the case of an RPC error. Adding error returns provides the mechanism
> we need.
>
> When the interfaces are changed to add error returns clients will see
> compile-time errors for any custom ORC-based stacks, derived symbol
> resolvers, or memory managers. Most clients will just be able to
> update their offending return types and leave their function body
> as-is (for Expected<T> returns) or return llvm::Error::success() (for
> Error returns). Clients who are actually using the remote-JITing
> features will now be able to return any errors that they had
> previously been dropping or bailing out on. This change is being
> tracked by https://llvm.org/PR22612 .
>
> I've held off making these changes for a while, because I know there
> are a lot of out-of-tree JIT clients and I want to avoid breaking your
> code. I think this churn is worth the pain though - the resulting APIs
> will have less historical baggage, be more error-proof, and enable
> some new features.
>
> Please let me know if you have any questions or run into any trouble
> as these changes land - I'll be happy to help out.
>
> Cheers,
> Lang.
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
https://about.me/stefan.graenitz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160527/5962dfea/attachment.html>