similar to: [LLVMdev] pseudo instructions not removed error

For anyone encountering this problem in the future, the cause of this problem was debugging symbols (-g) given to clang when generating IR. On 20/05/2012 12:21, "Weiss, Eran" <Eran.Weiss at emc.com> wrote: >Hi, > >I'm having problems when trying to JIT IR generated from C++ with clang. >My code resides in a dynamically loaded shared object, and crashes when I

Andrew, I've attached a small reproduction of the issue. Reproduce by: $ /usr/bin/g++ `llvm-config --cxxflags` -g -m32 -c mcjit_external_symbol.cpp $ /usr/bin/g++ `llvm-config --ldflags` -g -m32 -o mcjit_external_symbol mcjit_external_symbol.o `llvm-config --libs all` $ ./mcjit_external_symbol verifying... LLVM ERROR: Program used external function '_external' which could not be

Thanks, Eran. I’m not sure how soon I’ll have a solution for you, but it’s on my to-do list now. I’ll also create a bugzilla record for this problem. -Andy From: Weiss, Eran [mailto:Eran.Weiss at emc.com] Sent: Thursday, April 11, 2013 12:40 AM To: Kaylor, Andrew Cc: llvmdev at cs.uiuc.edu; Jim Grosbach; Jiong Wang Subject: Re: [LLVMdev] Migration from JIT to MCJIT Andrew, I've attached

Existing clients (LLDB) deal with externals by resolving them to constant function pointers that are referenced in the IR. That’s obviously ugly as hell, but it gets things done. The old JIT was able to simplify things because it assumed the JITed code was running in the same process as the JIT compiler. The MCJIT doesn’t assume that, so it has to handle more possibilities. For example, that the

Eran, Is there any chance you could boil this down to a small reproducer? I’ve got a mid-to-long-term goal of getting rid of the ugliness in LLDB that Jim mentioned, and fixing your problem would be a good first step. Thanks, Andy From: Jim Grosbach [mailto:grosbach at apple.com] Sent: Wednesday, April 10, 2013 4:19 PM To: Kaylor, Andrew; Jiong Wang Cc: Weiss, Eran; llvmdev at cs.uiuc.edu

Thank you for the help. The relocation type value is anded with 0xffffffffL. (RuntimeDyldMachO.cpp:214) Maybe this mask should be different? Anyway, it seems like this relocation isn't implemented. (RuntimeDyldMachO.cpp:104) From: Jiong Wang <jiwang at tilera.com<mailto:jiwang at tilera.com>> Date: Tue, 9 Apr 2013 09:42:03 -0400 To: Eran Weiss <eran.weiss at

The MachO handling isn’t always straightforward in that it has a lot of bit fields to handle while it’s also trying to accommodate the format abstractions baked into the interfaces. The actual relocation type gets extracted in the RuntimeDyldMachO::resolveRelocation function (RuntimeDyldMachO.cpp:32) before it is passed on to the architecture-specific handlers. So the mask you mentioned is

Hi, I have a problem with JIT code generation on mac. The LLVM-IR I have is fine, but the machine code generated crashes. I see two instructions "add %al,(%eax)" (which are four 0 bytes, numerically) prior to function calls. As eax holds the pointer to the called function, this crashes with SIGBUS. These instructions don't make sense in the context of the code, which is why

? 2013/4/9 21:08, Weiss, Eran ??: > Hi, > > I'm migrating my code (running on mac) from using JIT to MCJIT. My > code generates in memory, mostly using the llvm-c api, and then runs > the generated code. > When I try to use MCJIT I encounter a problem with relocations of > external symbols -- functions compiled statically beforehand with gcc. > > I get the

Hi, I'm migrating my code (running on mac) from using JIT to MCJIT. My code generates in memory, mostly using the llvm-c api, and then runs the generated code. When I try to use MCJIT I encounter a problem with relocations of external symbols – functions compiled statically beforehand with gcc. I get the following error: Invalid relocation type! UNREACHABLE executed at

Submitted to bugzilla as PR 15729 From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Kaylor, Andrew Sent: Thursday, April 11, 2013 1:13 PM To: Weiss, Eran Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Migration from JIT to MCJIT Thanks, Eran. I’m not sure how soon I’ll have a solution for you, but it’s on my to-do list now. I’ll also create a bugzilla

Hi, I want to be able add a function to a module after it is (partly) compiled in JIT. Let's say we have these functions: Foo() { Stuff; } Bar() { Foo(); MoreStuff; } I want to have a module with Foo optimized and have a callable pointer to Foo. Later, I want to generate Bar, optimize it (so Foo is inlined) and than get a callable pointer to Bar. Is this possible? If so, is there a way to

Hi, I'm a bit confused with regard to the use of x86 and i386 in clang and llvm tools. I'm using clang to emit llvm with –m32 on a x86-64 machine. This generates a file with a target triple that uses i386. >From the i386 llvm file I generate a .bc file with llvm-as. When I try to generate an object file with llc -mtriple x86 -filetype=obj I get the following error: llc: target does

On 2009-10-29 23:55, Jeffrey Yasskin wrote: > On Thu, Oct 29, 2009 at 2:30 PM, Nicolas Geoffray > <nicolas.geoffray at lip6.fr> wrote: > >> Hi Jeffrey, >> >> Jeffrey Yasskin wrote: >> >>> Cool, I'll start implementing it. >>> >>> >> Great! Thanks. >> >> Just to clarify things: on my end, it

On 2009-11-01 08:40, Jeffrey Yasskin wrote: > 2009/10/30 Török Edwin <edwintorok at gmail.com>: > >> On 2009-10-29 23:55, Jeffrey Yasskin wrote: >> >>> On Thu, Oct 29, 2009 at 2:30 PM, Nicolas Geoffray >>> <nicolas.geoffray at lip6.fr> wrote: >>> >>> >>>> Hi Jeffrey, >>>> >>>>

2009/10/30 Török Edwin <edwintorok at gmail.com>: > On 2009-10-29 23:55, Jeffrey Yasskin wrote: >> On Thu, Oct 29, 2009 at 2:30 PM, Nicolas Geoffray >> <nicolas.geoffray at lip6.fr> wrote: >> >>> Hi Jeffrey, >>> >>> Jeffrey Yasskin wrote: >>> >>>> Cool, I'll start implementing it. >>>> >>>>

Thu Jul 12 03:42:12 CDT 2012, Verena Beckham verena at codeplay.com : > I would not say it is trivial, having done it myself. > > MCJIT also doesn't support multiple modules, and it does not do JITing > on demand, instead, it does all of it at the same time in the > constructor (unless that is what you call "not lazy"). > So depending on how you've written your

I am trying to JIT some code containing an indirect branch (and the corresponding store i8* blockaddress(@label)). I am using LLVM 2.7 code base. I build the ExecutionEngine using EngineBuilder, and call engine->getPointerToFunction(func). When I use setOptLevel(llvm::CodeGenOpt::None), the JITing fails with the following message : JIT.h:131: virtual void*

Hi Pawel, Some of the issues I have come across (from memory!) are * MCJIT doesn't work on Windows, because it doesn't support COFF. If you want to use it on Windows you have to either target Mach-O (not clear whether that will work in general) or ELF (need to get a patch from Intel to be able to use this). * Make sure you include MCJIT.h and link in MCJIT.lib, otherwise (even if

On Thu, Oct 29, 2009 at 2:30 PM, Nicolas Geoffray <nicolas.geoffray at lip6.fr> wrote: > Hi Jeffrey, > > Jeffrey Yasskin wrote: >> >> Cool, I'll start implementing it. >> > > Great! Thanks. > > Just to clarify things: on my end, it doesn't really matter what is the > default behavior, as long as vmkit can continue to have the existing >