search for: addobjectset

Hi all, I am having hard time figuring out how I should use the API for JIT in LLVM 6. In LLVM 3.9 I am used to adding all objects at once and emitAndFinalizing them all: handle = objectLayer.addObjectSet(objectFiles, memoryManager, resolver); objectLayer.emitAndFinalize(handle); In LLVM 6.0 the objects are added one by one: auto handle = objectLayer.addObject(objectFile, resolver).get(); objectLayer.emitAndFinalize(handle); The problem is that emitAndFinalize in this case works for one module an...

...llvm-dev at lists.llvm.org> Date: 16.05.2017 18:37 Subject: Re: JIT - Resolve obj file without a main Hi Björn, I don't recall ever seeing this behavior before. Can you describe the situation in more detail? Is this specifically for object files loaded via RTDyldLinkingLayer::addObjectSet, or does it apply to IR Modules without a main too? When you say the JIT won't resolve an address, do you mean that you can't find anything when you call findSymbol on the JIT, or that the JIT isn't calling your SymbolResolver back to find addresses? Was this for MacOS, Linux, or W...

Hello Lang, I noticed, if I load a obj-File without a main-function, the Jitter won't resolve any address. But if I have a main, everything works fine. Why is this so? Is there a way to stop this? Kind regards Björn Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816, USt.ID-Nr. DE 114 165 789 Geschäftsführer: Hiroshi Kawamura, Dr Hiroshi Nakamura, Markus Bode, Heiko

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 resolveRelocations is normally the main job of ObjectLinkingLayer and as I said I can create my own ObjectLinkingLayer or something instead of...

...lists.llvm.org> Date: 16.05.2017 18:37 Subject: Re: JIT - Resolve obj file without a main Hi Björn, I don't recall ever seeing this behavior before. Can you describe the situation in more detail? Is this specifically for object files loaded via RTDyldLinkingLayer::addObjectSet, or does it apply to IR Modules without a main too? When you say the JIT won't resolve an address, do you mean that you can't find anything when you call findSymbol on the JIT, or that the JIT isn't calling your SymbolResolver back to find addresses? Was this for MacOS, Linux, or...

...feld at microsoft.com> wrote: > 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 resolveRelocations is normally the main job of > ObjectLinkingLayer and as I said I can create my own ObjectLi...

Agreed, that sounds like the best plan. I'll look into moving LLILC to ORC. Thanks -Joseph From: Russell Hadley Sent: Friday, May 29, 2015 8:13 PM To: Lang Hames; Joseph Tremoulet Cc: llvmdev at cs.uiuc.edu Subject: RE: [LLVMdev] MCJit interface question Hey Joseph, What Lang said made me wonder. Is it the right time for us (LLILC) to move to ORC? The long term plan was to go there but

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

...s great. :) > > Do you know if there is a way to directly load .obj-Files and resolve the > references with own addresses? Like when somebody used printf in the > generated obj-File, but I replace the address with my own printf? > > You can load precompiled object files by calling addObjectSet on the > ObjectLayer. > > All external symbol references are resolved by the JITSymbolResolver that > is created by createLambdaResolver. In your example the resolution process > is two-step: First the JIT searches its own function definitions to see if > there is a function calle...

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

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