similar to: [LLVMdev] write shared object file in memory

I'm trying to add static code generation capabilities to my MCJIT compiler on LLVM 3.4. To that extent I have: targetMachine = engineBuilder.selectTarget(); // ... targetMachine->addPassesToEmitFile(<...>); At first glance this appears to work, but when linking the object file I get the warning: ld: warning: PIE disabled. Absolute addressing (perhaps

I'm not sure I understand your use case, but MCJIT (as opposed to the legacy JIT) does almost exactly what you're asking for. It generates an in-memory object file image (using addPassesToEmitMC) and then loads and links it for execution. If there's some particular detail you don't like in the way this is happening, you might be able to generate a file as you have and then use

Hi, I'm building LLVM IR. I'd like to compile this IR to native code (I don't want JIT) and immediately load it to execute. So far, I've the following: 1) I can emit the IR to native assembly/object file doing the same thing llc does (using TargetMachine::addPassesToEmitFile). 2) I can dynamically load a precompiled .so file (using llvm::sys::DynamicLibrary::getPermanentLibrary),

Right now, I am using TargetMachine::addPassesToEmitFile <http://llvm.org/docs/doxygen/html/classllvm_1_1LLVMTargetMachine.html#a356929c1f0d202e4a9d3202aff1dbb05> to write the output of a backend to a file. How can I tell LLVM to write into a memory buffer instead? -------------- next part -------------- An HTML attachment was scrubbed... URL:

We generating object files, not using the JIT so I don't know if those fixes applies in our case. As far as using PIC goes, the ELFCodeEmitter has asserts to tell you that PIC isn't currently supported. Will have to get the 2.7 update and try it out. Thanks. -----Original Message----- From: Howell, Nathan [mailto:nhowell at ebay.com] Sent: Thursday, June 17, 2010 3:45 PM To: Eli

Take a look at the MCJIT unit tests under unittests/ExecutionEngine/MCJIT The MCJITTestBase class does the majority of the interactions with the LLVM API you're referring to. Good luck, Dan On 2012-10-13, at 4:57 AM, "Armin Steinhoff" <as at steinhoff-automation.com> wrote: > > Kaylor, > > do you have some good documented example code which shows the usage of

Kaylor, do you have some good documented example code which shows the usage of the MCJIT ? This would help a lot ... the sematic of lots of API calls are not intuitively understandable. Best Regards --Armin Kaylor, Andrew wrote: > I'm not sure I understand your use case, but MCJIT (as opposed to the legacy JIT) does almost exactly what you're asking for. It generates an

It's definitely there. It was added in r165246 recently so you probably have an older version. Amara On 13 October 2012 23:02, Armin Steinhoff <as at steinhoff-automation.com> wrote: > Daniel, > > I didn't find the MCJIT directory under unitests/ExecutionEngine ... there > is only a directory called JIT. > You mean this directory ? > > Many thanks > >

Daniel, I didn't find the MCJIT directory under unitests/ExecutionEngine ... there is only a directory called JIT. You mean this directory ? Many thanks --Armin Malea, Daniel wrote: > Take a look at the MCJIT unit tests under unittests/ExecutionEngine/MCJIT > > The MCJITTestBase class does the majority of the interactions with the LLVM API you're referring to. > >

Hi, I'm embarrassed that I can't figure this out... I have a compiler that outputs my module in either .s assembly format or .obj binary format, either one works just fine. But if I try to output both of them by adding passes, LLVM throws an Assert: void WinCOFFStreamer::EmitLabel(MCSymbol *Symbol) { assert(Symbol->isUndefined() && "Cannot define a symbol

Aaron, > Maybe we should collect references and do some LLVM PIC documentation and > put it on LLVM website ? What you mean as "LLVM PIC documentation"? What should be included there? > Okay. We need documentation, what is the difference between DynamicNoPIC and > full PIC ? >From TargetMachine.cpp (actually this is show in llc --help): cl::values(

I had this problem a while back and received this response from Jeffrey. FWIW this is fixed in 2.7 by defaulting to CodeModel::Large and using indirect (far) calls. -----Original Message----- From: Jeffrey Yasskin [mailto:jyasskin at google.com] Sent: Monday, December 07, 2009 11:32 AM To: Howell, Nathan Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] 2.6 JIT using wrong address for

Well, I've been before hours trying this, but soon after I sent the email I found something. However is quite intriguing. I just changed the order of and the static libraries that I was linking. How can this be possible?? I'm using Cmake for building my llvm projects, so I choose the order and I pick the .a libraries I want to link by hand... Thank you, alvaro 2009/3/8 Álvaro

Chris Lattner wrote: > On Mar 27, 2010, at 12:49 PM, Peter Shugalev wrote: > >>>> New method of emitting object code is ok for me. But it is still >>>> experimental, isn't it? >>> Yes. >> Thank you for answers! >> >> Now there is a way to implement what I'd like to. But it would be MUCH >> better if

On Mar 27, 2010, at 1:50 PM, Peter Shugalev wrote: > Chris Lattner wrote: >> On Mar 27, 2010, at 12:49 PM, Peter Shugalev wrote: >> >>>>> New method of emitting object code is ok for me. But it is still >>>>> experimental, isn't it? >>>> Yes. >>> Thank you for answers! >>> >>> Now there is a way to implement

Hi, Long time ago (llvm-svn june 2008) I asked here about a way to output the assembly code of my JIT generated code to a string, so I could use it to read it on the screen. I came up with this solution: std::string Err; const llvm::TargetMachineRegistry::entry* _arch = llvm::TargetMachineRegistry::getClosestTargetForJIT(Err); std::string FeaturesStr; llvm::TargetMachine*

On Sun, 21 Jan 2007, Marcel Weiher wrote: > just installed the new llvm 1.9 build and noticed that my code no > longer worked. It seems something has changed with > addPassesToEmitFile(). First, the arguments to that method changed so > that it no longer takes a PassManager, but only a > FunctionPassManager. Instead there is a addPassesToEmitWholeFile() > method, but that is

When you say 'static libraries' do you mean static libraries or shared objects (.so)... Because if you mean shared objects, then it could very well explain you crash. On Mar 9, 12:16 am, Álvaro Castro Castilla <alvaro.castro.casti... at gmail.com> wrote: > Well, I've been before hours trying this, but soon after I sent the > email I found something. However is quite

H all, I'm looking at generating PIC code for RISC-V in the context of Linux. Not sure if anyone is working on this already, any inputs are very welcome. I'm now looking at function calls which in the RISCV backend are represented via two pseudoinstructions RISCV::TAIL and RISCV::CALL. Currently those pseudos are lowered in MCCodeEmitter. They are expanded into AUIPC and JALR

On Thu, Jun 17, 2010 at 12:38 PM, Smith, Tim <tim at bioware.com> wrote: > (llvm 2.6) > > > > We have an application where we are using LLVM to generate ELF object files > for X86_64.   At runtime we load these objects files into memory using our > own ELF loader. > > > > Everything is working except for the jump tables. > > > > The ELF emitter is