Sean Ogden via llvm-dev
2016-Mar-02 14:05 UTC
[llvm-dev] findSymbol vs. FindSymbolInLogicalDylib?
Can someone point me to some information that will help me understand the difference between RuntimeDyld::SymbolResolver::findSymbol and RuntimeDyld::SymbolResolver::findSymbolInLogicalDylib? What is a logical dylib? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160302/da222308/attachment.html>
Lang Hames via llvm-dev
2016-Mar-02 22:32 UTC
[llvm-dev] findSymbol vs. FindSymbolInLogicalDylib?
Hi Sean, I'm not sure there's any great documentation other than the comments in RuntimeDyld.h. The short version is that findSymbolInLogicalDylib is there to try to mimic the static linker's resolution rules (though from memory it's only roughly approximating that at the moment). When the JIT linker encounters an undefined (or common linkage) symbol it will first search for a definition using findSymbolInLogicalDylib. If that doesn't return a result then the JIT will fall back to searching findSymbol to find an external definition. Most people just compile isolated IR modules, in which case you can ignore findSymbolInLogicalDylib and just fill in findSymbol. If you have a use-case for linking multiple objects as if they were all part of a dylib you can override findSymbolInLogicalDylib to search the symbols. Hope this helps. Cheers, Lang. On Wed, Mar 2, 2016 at 6:05 AM, Sean Ogden via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Can someone point me to some information that will help me understand the > difference between RuntimeDyld::SymbolResolver::findSymbol and RuntimeDyld::SymbolResolver::findSymbolInLogicalDylib? > What is a logical dylib? > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160302/311233ed/attachment.html>