similar to: [LLVMdev] LoadedObjectInfo::getSectionLoadAddress

On Wed, Jul 22, 2015 at 9:41 PM, Eugene Rozenfeld <Eugene.Rozenfeld at microsoft.com> wrote: > Hi Lang, > > > > LoadedObjectInfo::getSectionLoadAddress takes StringRef as an arg. That > breaks if the object file has multiple sections with the same name. I made a > change to add an overload that takes a SectionRef&. Can you please take a > look? > > >

No real reason, just wanted to get an informal opinion first. Submitted via Phabricator now. http://reviews.llvm.org/D11474 Eugene -----Original Message----- From: Meador Inge [mailto:meadori at gmail.com] Sent: Thursday, July 23, 2015 8:45 AM To: Eugene Rozenfeld <Eugene.Rozenfeld at microsoft.com> Cc: Lang Hames <lhames at gmail.com>; llvmdev at cs.uiuc.edu Subject: Re:

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

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.

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

Hi Lang, It turns out I also need an ability to tell the object linking layer not to apply any relocations. I need to skip this step below. The only way I can see I can achieve that is by creating my own ObjectLinkingLayer that would duplicate almost all of orc::ObjectLinkingLayer. I’d like to avoid that. An alternative it to pass a flag to orc::ObjectLinkingLayer constructor and

Yes, I’m handling all internal and external relocations manually in NotifyLoadedFtor and I already verified that I get the behavior I need if I comment out the call to resolveRelocations. I would like to reuse ObjectLinkingLayer::addObjectSet (which eventually calls RuntimeDyld::loadObject), which has the right calls to the memory manager and also RuntimeDyld::registerEHFrames. I understand that

Hi Eugene, Skipping the call to resolveRelocations would disable many (if not all) internal relocations too. Is that the desired behavior? At that point there's not much left for RuntimeDyld (or the ObjectLinkingLayer) to do. Would something like a NoopLinkingLayer be a workable solution? Cheers, Lang. On Wed, Jul 22, 2015 at 7:26 PM, Eugene Rozenfeld < Eugene.Rozenfeld at

Hi Eugene, Sorry for the delayed reply. Custom relocations weren't something I had in mind when I designed Orc, so they raise some interesting design questions which I don't have good answers to yet. (E.g. The interface for the Orc layer concept assumes that there's a RuntimeDyld instance embedded at the bottom of the stack. That's why addModuleSet takes a MemoryManager and

Hi On Windows 10 when using a debug build of LLVM 10, I get this assertion failure: Assertion failed: (KV.second.getFlags() & ~WeakFlags) == (I->second & ~WeakFlags) && "Resolving symbol with incorrect flags", file C:\work\github\llvm-10.0.0.src\lib\ExecutionEngine\Orc\Core.cpp, line 450 The same failure occurred in LLVM 9 too: Assertion failed: I->second ==

Hi all, hi Lang It's a little late to report issues for release_50, but I just found that thing while porting my JitFromScratch examples to 5.0. This is a really nifty detail, but (if I'm not mistaken) the function signature of RTDyldObjectLinkingLayer::NotifyLoadedFtor is incorrect: $ grep -h -r -A 1 "using NotifyLoadedFtor"

> So I'm using "llvm/ExecutionEngine/MCJIT.h" instead of > "llvm/ExecutionEngine/JIT.h", and I've added setUseMCJIT(true) to > EngineBuilder, but what actually happens is: > > LLVM ERROR: Target does not support MC emission! > > Do I need to do anything else? IIRC, this error might be due to not linking against the MCJIT library component. Add the

Hi all, Attention: Lang Hames I am developing the nGraph MLIR<https://github.com/NervanaSystems/ngraph/tree/master/src/contrib/mlir> implementation and hitting the following assert while running nGraph unit tests: assert(ObjectBufferMap.find(K) == ObjectBufferMap.end() && "Second attempt to perform debug registration."); Here is a

Hi Adam, Calls to the listeners should be protected by the RTDyldLayerMutex. Could you apply the attached patch and share the debugging output from one of the failing runs? Regards, Lang. On Wed, May 20, 2020 at 8:00 PM David Blaikie <dblaikie at gmail.com> wrote: > +Lang > > On Wed, May 20, 2020 at 4:44 PM Straw, Adam D via llvm-dev < > llvm-dev at lists.llvm.org>

Referring to the log messages from my previous mail… I confused myself (and probably others) by reading the “Adding MemMgr 0x55555959f440“ message as “Registering MemMgr 0x55555959f440”. Thus the address mismatch made no sense. How could we be registering a `MemMgr` address/key that does not match once we arrive in `notifyObjectLoaded` method? Answer: Because the registrations is NOT coming

Hi, I've been trying to write a tool that reads in an ELF file and modifies one section within that ELF file based on the data contained within another section. Using llvm-objdump as a template of how to read an object file, I've been able to read the latter section that tells me what to edit, but I haven't found a way to edit the former, as everything in the

I'd like to generate an indirect call instruction that will end up as a call via memory and not register. The address of the target is a constant. For example, something like %25 = load i64, i64* @get_Now %26 = inttoptr i64 %25 to i64 ()* %27 = call i64 %26() may end up as mov rsi,qword ptr [00007FF658381070] call rsi or as call qword ptr [00007FF658381070] If I want to

On Thu, Feb 07, 2013 at 09:53:39PM +1100, Vadim Rozenfeld wrote: > On Thu, 2013-02-07 at 12:18 +0200, Michael S. Tsirkin wrote: > > On Thu, Feb 07, 2013 at 08:24:10PM +1100, Vadim Rozenfeld wrote: > > > On Thu, 2013-02-07 at 11:33 +1030, Rusty Russell wrote: > > > > Vadim Rozenfeld <vrozenfe at redhat.com> writes: > > > > > On Tue, 2013-02-05 at

On Thu, Feb 07, 2013 at 09:53:39PM +1100, Vadim Rozenfeld wrote: > On Thu, 2013-02-07 at 12:18 +0200, Michael S. Tsirkin wrote: > > On Thu, Feb 07, 2013 at 08:24:10PM +1100, Vadim Rozenfeld wrote: > > > On Thu, 2013-02-07 at 11:33 +1030, Rusty Russell wrote: > > > > Vadim Rozenfeld <vrozenfe at redhat.com> writes: > > > > > On Tue, 2013-02-05 at

On Wed, Oct 28, 2015 at 12:10:19PM +1100, Vadim Rozenfeld wrote: > > > > To sum up, the packaging and naming policy of the virtio-win rpm and the > > > > virtio-win iso therein are different and neither is clear. Hardcoding > > > > the policy in v2v without actually knowing it appears risky at best. > > It's due to historical reasons mostly. The best