[LLVMdev] MCJIT

[Ashok Nalkund]

I was able to get past the error by calling 
InitializeNativeTargetAsmParser() in my code. Now I have a failure in 
resolving external libraries, so looking into that (recompiled with 
--enable-ffi but I now get an error LLVMgold.so not found).

Then I hda to disable the following code in 
lib/Target/X86/X86CodeEmitter.cpp:
>       case TargetOpcode::INLINEASM:
>         // We allow inline assembler nodes with empty bodies - they can
>         // implicitly define registers, which is ok for JIT.
>         //if (MI.getOperand(0).getSymbolName()[0])
>         //  report_fatal_error("in X86CodeEmitter.cpp JIT does not support inline asm!");
>         break;

otherwise, when it sees a non-zero char in the inline asm (say load) and 
report failure and die.

Also, I also had to link in ${LLVM_TARGETS_TO_BUILD} into lli for it to 
compile after adding InitializeNativeTargetAsmParser() call in lli.cpp.

Can you point me how to resolve external symbols in my app (or how to 
enable it in lli)?

thanks,
ashok

On 5/14/2012 8:45 AM, Jim Grosbach wrote:
> Inline asm should work in the MCJIT just as well as it does in statically compiled code. It's the same code path for both. The error you're seeing indicates that something isn't configured in a way the compiler understands.
>
> -Jim
>
> On May 12, 2012, at 10:48 AM, Ashok Nalkund wrote:
>
>> Can you also tell about inline-asm support in MCJIT for x86? I've been
>> trying to get it to work (my previous post: "JIT support for inline asm
>> on Linux"), I get an error:
>>
>>> LLVM ERROR: Inline asm not supported by this streamer because we don't
>>> have an asm parser for this target
>>
>> thanks,
>> ashok
>>
>> On 5/11/2012 12:44 PM, Kaylor, Andrew wrote:
>>> Hi Braxton,
>>>
>>> I think it’s very good. All of the ExecutionEngine tests pass. I’m not
>>> aware of any major defects.
>>>
>>> I don’t believe that the current implementation sets the permissions on
>>> JITed memory as you might wish. Namely, I think executable memory may be
>>> left writeable and data memory may be executable. The current interface
>>> is also somewhat limited. Basically, you pass a Module to the
>>> constructor, it JITs that Module immediately and then you can get the
>>> address of individual functions to execute them. What is there works though.
>>>
>>> -Andy
>>>
>>> *From:*llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
>>> *On Behalf Of *Braxton McKee
>>> *Sent:* Thursday, May 10, 2012 10:53 AM
>>> *To:* llvmdev at cs.uiuc.edu
>>> *Subject:* [LLVMdev] MCJIT
>>>
>>> Hi All,
>>>
>>> What is the current level of stability of MCJIT using ELF?
>>>
>>> Thanks.
>>>
>>> --
>>> -------------------------------------------------------------------------------------------
>>> Braxton McKee Broad Street Analytics
>>> www.twitter.com/braxtonmckee<http://www.twitter.com/braxtonmckee>
>>> www.broadstreetanalytics.com<http://www.broadstreetanalytics.com>
>>>
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev