search for: externalsymbolreloc

Hi Lang, Can you please let me know you think it would be right to modify RuntimeDyldImpl::resolveExternalSymbols to allow resolvers to return 0 addresses? Something like this would be ideal for me: void RuntimeDyldImpl::resolveExternalSymbols() { while (!ExternalSymbolRelocations.empty()) { StringMap<RelocationList>::iterator i = ExternalSymbolRelocations.begin(); StringRef Name = i->first(); if (Name.size() == 0) { // This is an absolute symbol, use an address of zero. DEBUG(dbgs() << "Resolving absolute relocations."...

Hi Lang, Yes, I can return a non-zero marker value. Are you ok with this version? void RuntimeDyldImpl::resolveExternalSymbols() { while (!ExternalSymbolRelocations.empty()) { StringMap<RelocationList>::iterator i = ExternalSymbolRelocations.begin(); StringRef Name = i->first(); if (Name.size() == 0) { // This is an absolute symbol, use an address of zero. DEBUG(dbgs() << "Resolving absolute relocations."...

Hello, I'm working on LLILC (a jit for the CoreCLR built on ORC), in particular, on using LLILC as an ngen jit. I would like to have an ability to be notified of relocations that ObjectLinkingLayer is applying and to be able to tell the linking layer not to resolve certain relocations for external symbols (so that the client can do some custom resolutions later). The only way I found of

...s, Lang. On Mon, Jun 29, 2015 at 7:31 PM, Eugene Rozenfeld <Eugene.Rozenfeld at microsoft.com<mailto:Eugene.Rozenfeld at microsoft.com>> wrote: Hi Lang, Yes, I can return a non-zero marker value. Are you ok with this version? void RuntimeDyldImpl::resolveExternalSymbols() { while (!ExternalSymbolRelocations.empty()) { StringMap<RelocationList>::iterator i = ExternalSymbolRelocations.begin(); StringRef Name = i->first(); if (Name.size() == 0) { // This is an absolute symbol, use an address of zero. DEBUG(dbgs() << "Resolving absolute relocations."...

...Jun 29, 2015 at 7:31 PM, Eugene Rozenfeld < > Eugene.Rozenfeld at microsoft.com> wrote: > > Hi Lang, > > > > Yes, I can return a non-zero marker value. Are you ok with this version? > > > > void RuntimeDyldImpl::resolveExternalSymbols() { > > while (!ExternalSymbolRelocations.empty()) { > > StringMap<RelocationList>::iterator > i = ExternalSymbolRelocations.begin(); > > > > StringRef Name = i->first(); > > if (Name.size() == 0) { > > // This is an absolute symbol, use an address of zero. > >...

...s, Lang. On Mon, Jun 29, 2015 at 7:31 PM, Eugene Rozenfeld <Eugene.Rozenfeld at microsoft.com<mailto:Eugene.Rozenfeld at microsoft.com>> wrote: Hi Lang, Yes, I can return a non-zero marker value. Are you ok with this version? void RuntimeDyldImpl::resolveExternalSymbols() { while (!ExternalSymbolRelocations.empty()) { StringMap<RelocationList>::iterator i = ExternalSymbolRelocations.begin(); StringRef Name = i->first(); if (Name.size() == 0) { // This is an absolute symbol, use an address of zero. DEBUG(dbgs() << "Resolving absolute relocations."...

...Jun 29, 2015 at 7:31 PM, Eugene Rozenfeld < > Eugene.Rozenfeld at microsoft.com> wrote: > > Hi Lang, > > > > Yes, I can return a non-zero marker value. Are you ok with this version? > > > > void RuntimeDyldImpl::resolveExternalSymbols() { > > while (!ExternalSymbolRelocations.empty()) { > > StringMap<RelocationList>::iterator > i = ExternalSymbolRelocations.begin(); > > > > StringRef Name = i->first(); > > if (Name.size() == 0) { > > // This is an absolute symbol, use an address of zero. > >...

...ions. 4. Copy over the relocated code to buffers allocated by our custom allocator. The problem: After running step (1) we may, in rare cases, decide that the generated code is not usable by our runtime [*], and we have to "abort" the compile. However, step (1) populates Dyld->ExternalSymbolRelocations (and possibly other similar data structures) with the set of pending relocations, and the ExecutionEngine interface provides no way of cleaning this up without running (3). Since we use a single long-living instance of MCJIT per compiler thread, when we abort the compile after running (1) an...

...07237 Here is the overview of changes I promised a couple of weeks back. These comments are based on the 3.3 trunk of about 3 weeks ago. -- RuntimeDyld -- Relocations needs to be cleared between each emitObject. New method required: clearRelocations void RuntimeDyldImpl::clearRelocations() { ExternalSymbolRelocations.clear(); Relocations.clear(); } void RuntimeDyld::clearRelocations() { Dyld->clearRelocations(); } -- RuntimeDyldImpl -- void clearRelocations(); -- SectionMemoryManager -- Removed option in allocateSection to use existing 'free' memory regions - i.e. now always allocat...

Hey Andy, Yep I've tested some non-trivial examples with loads of dependencies, both code and data, global, local and external symbol resolution etc.. Actually this was truly a piece of cake, nothing to do, the memory manager is working really nicely so far as I can tell. Relocations to sections are all working as expected (aside from previously mentioned ARM issue which is probably just