search for: logicalmodul

Hi Sean, This is great, but it couples LogicalDylib too tightly to CompileOnDemandLayer. Does this alternative implementation of getLogicalModuleResourcesForSymbol work for you (unfortunately I don't have a local test case for this yet): LogicalModuleResources* getLogicalModuleResourcesForSymbol(const std::string &Name, bool ExportedSymbolsOnly) { for (auto LMI = LogicalModules.begin...

...r; } +public: + TargetAddress updatePointer(std::string FuncName, TargetAddress FnBodyAddr) { + //Find out which logical dylib contains our symbol + auto LDI = LogicalDylibs.begin(); + for (auto LDE = LogicalDylibs.end(); LDI != LDE; ++LDI) { + if (auto LMResources = LDI->getLogicalModuleResourcesForSymbol(FuncName, false)) { + Module &SrcM = LMResources->SourceModule->getResource(); + std::string CalledFnName = mangle(FuncName, SrcM.getDataLayout()); + if (auto EC = LMResources->StubsMgr->updatePointer(CalledFnName, FnBodyAddr)) { +...

...untime, and I'd be willing to work on adding that support. On Fri, Jul 29, 2016 at 6:53 PM Lang Hames <lhames at gmail.com> wrote: > Hi Sean, > > This is great, but it couples LogicalDylib too tightly to > CompileOnDemandLayer. Does this alternative implementation of > getLogicalModuleResourcesForSymbol work for you (unfortunately I don't > have a local test case for this yet): > > > > > > LogicalModuleResources* > getLogicalModuleResourcesForSymbol(const std::string &Name, > bool ExportedSymbolsOnly) {...

...ress updatePointer(std::string FuncName, TargetAddress > FnBodyAddr) { > + //Find out which logical dylib contains our symbol > + auto LDI = LogicalDylibs.begin(); > + for (auto LDE = LogicalDylibs.end(); LDI != LDE; ++LDI) { > + if (auto LMResources = > LDI->getLogicalModuleResourcesForSymbol(FuncName, false)) { > + Module &SrcM = LMResources->SourceModule->getResource(); > + std::string CalledFnName = mangle(FuncName, > SrcM.getDataLayout()); > + if (auto EC = > LMResources->StubsMgr->updatePointer(Calle...

...own specialized version of CompileOnDemandLayer.h that includes > this functionality, or do you have any ideas for a cleaner way to do this? My apologies - I wasn't very clear in my description of the issue. The only sense in which your original patch was tightly coupled was that it had getLogicalModuleResourcesForSymbol accessing LogicalModuleResources::SourceModule, which isn't a required part of the 'LogicalModuleResources' interface at the moment. The alternative implementation of getLogicalModuleResourcesForSymbol doesn't have that coupling, and since it works for you I think...