[LLVMdev] Fail to load a pointer to a function inside MCJIT-ed code when it is reload from ObjectCache

[Lang Hames]

Hi Cheng,

It sounds like the either (1) 0x7fe4801fa1f8 is part of the environment,
and it's not being configured the same way the 2nd time around, or (2) The
JIT is handling on-disk objects differently from in-memory ones. The first
option is more likely.

It would be helpful if you could attach the object that was stored in your
cache.

Cheers,
Lang.

On Thu, Sep 11, 2014 at 10:58 AM, Cheng Zhu <chengzhu at gmail.com> wrote:

> Hi, All
>
> I have a problem to reuse mcjit jitted code loaded from ObjectCache from a
> file. In the first run, I use MCJIT generate function JittedOpExpr object
> code as following and it runs OK. 0x7fe4801fa1f8 at instruction
> 0x00007fe4cc6c2014 points to 0x69382E which is the beginning of ExecEvalVar
> function. Then I save the object code into a file after implementing
> notifyObjectCompiled method.
>
>
>                     IrExprGetValue:
> 0x00007fe4cc6c2000:   push %rbp
> 0x00007fe4cc6c2001:   mov %rsp,%rbp
> 0x00007fe4cc6c2004:   mov 0x10(%rdi),%rax
> 0x00007fe4cc6c2008:   pop %rbp
> 0x00007fe4cc6c2009:   jmpq *%rax
> 0x00007fe4cc6c200b:   nopl 0x0(%rax,%rax,1)
>                     JittedOpExpr:
> 0x00007fe4cc6c2010:   push %rbp
> 0x00007fe4cc6c2011:   mov %rsp,%rbp
> *0x00007fe4cc6c2014:   movabs $0x7fe4801fa1f8,%rax*
> 0x00007fe4cc6c201e:   movabs $0x7fe4801fa1e8,%rdi
> 0x00007fe4cc6c2028:   callq *(%rax)
> 0x00007fe4cc6c202a:   add $0x5,%rax
> 0x00007fe4cc6c202e:   pop %rbp
> 0x00007fe4cc6c202f:   retq
> 0x00007fe4cc6c2030:   adc $0x0,%al
> 0x00007fe4cc6c2032:   add %al,(%rax)
> 0x00007fe4cc6c2034:   add %al,(%rax)
>
> *0x7fe4801fa1f8 -> 0x69382E*
> *                    ExecEvalVar*(ExprState*, ExprContext*, bool*,
> ExprDoneCond*):
> 0x000000000069382e:   push %rbp
> 0x000000000069382f:   mov %rsp,%rbp
> 0x0000000000693832:   push %r12
>
> In the next run, I buildedunction of JittedOpExpr again and loaded
> compiled object from that saved binary file using getObject and went
> through getPointertoFunction from MCJIT execution engine, I got the
> following object code in memory. But this time 0x7fe4801fa1f8 points to
> 0x0, so when callq *(%rax) it couldn't find the ExecEvalVar anymore. I
> followed the blog "Object Caching with the Kaleidoscope Example Problem"
> written by Andy Kaylor by implementing my own MCJITObjectCache class. Did I
> miss anything here? Thank you very much.
>
>                     IrExprGetValue:
> 0x00007fe4cc6c2000:   push %rbp
> 0x00007fe4cc6c2001:   mov %rsp,%rbp
> 0x00007fe4cc6c2004:   mov 0x10(%rdi),%rax
> 0x00007fe4cc6c2008:   pop %rbp
> 0x00007fe4cc6c2009:   jmpq *%rax
> 0x00007fe4cc6c200b:   nopl 0x0(%rax,%rax,1)
>                     JittedOpExpr:
> 0x00007fe4cc6c2010:   push %rbp
> 0x00007fe4cc6c2011:   mov %rsp,%rbp
> *0x00007fe4cc6c2014:   movabs $0x7fe4801fa1f8,%rax*
> 0x00007fe4cc6c201e:   movabs $0x7fe4801fa1e8,%rdi
> 0x00007fe4cc6c2028:   callq *(%rax)
> 0x00007fe4cc6c202a:   add $0x5,%rax
> 0x00007fe4cc6c202e:   pop %rbp
> 0x00007fe4cc6c202f:   retq
>
> *but 0x7fe4801fa1f8 -> 000000000*
>
> --
> Best regards
>
> Cheng
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140911/38970494/attachment.html>