[LLVMdev] 2.6 JIT using wrong address for external functions

Jeffrey Yasskin jyasskin at google.com
Mon Dec 7 11:32:12 PST 2009


I had that problem too: http://llvm.org/bugs/show_bug.cgi?id=5116. To
work around the problem, you can:
 * Switch to the thread-unsafe lazy jit.
 * Allocate your JIT code within 2GB of your text segment.
 * Find a way to look up the external function with dlsym or maybe the
ExecutionEngine's LazyFunctionCreator instead of addGlobalMapping.
 * Upgrade to the top of the svn tree.

On Mon, Dec 7, 2009 at 10:01 AM, Howell, Nathan <nhowell at ebay.com> wrote:
> I have an external function that was added with
> ExecutionEngine::addGlobalMapping... and the JIT is burning the wrong
> address into the emitted function. All of the addresses have
> 0xffffff8d00000000 added to them. Does this look familiar to anyone? I'm
> using 2.6 on Solaris10/x64 if it matters.
>
> This has been working for about two months and I can't readily figure
> out what I changed to break it.
>
> tia,
> -n
>
>
> define i64 @"extern::427433251261"(%struct.ContextFrame* %context, i64*
> nocapture %params, i64 %paramCount) {
> entry:
>  %correctParamCount = icmp eq i64 %paramCount, 0 ; <i1> [#uses=1]
>  br i1 %correctParamCount, label %copyParams, label %invalidParams
>
> copyParams:                                       ; preds = %entry
>  %tmp4.i.i.i.i.i = tail call i64
> @ContextFrame_getInt64Value(%struct.ContextFrame* %context, i32 0, i64
> 726) nounwind readonly ; <i64> [#uses=1]
>  %tmp23.i.i.i.i.i = sitofp i64 %tmp4.i.i.i.i.i to double ; <double>
> [#uses=1]
> ...
>
>
> (gdb) x/100i 0xfffffd7ff9302528
> 0xfffffd7ff9302528:     push   %r14
> 0xfffffd7ff930252a:     push   %rbx
> 0xfffffd7ff930252b:     sub    $0x18,%rsp
> 0xfffffd7ff930252f:     test   %rdx,%rdx
> 0xfffffd7ff9302532:     jne    0xfffffd7ff9302747
> 0xfffffd7ff9302538:     mov    %rdi,%rbx
> 0xfffffd7ff930253b:     xor    %r14d,%r14d
> 0xfffffd7ff930253e:     mov    $0x2d6,%edx
> 0xfffffd7ff9302543:     mov    %rbx,%rdi
> 0xfffffd7ff9302546:     mov    %r14d,%esi
>>>> 0xfffffd7ff9302549:     callq  0xfffffd800066f690
> 0xfffffd7ff930254e:     cvtsi2sd %rax,%xmm0
> 0xfffffd7ff9302553:     mov    $0xfffffd7ff93024d0,%rax
> 0xfffffd7ff930255d:     movsd  (%rax),%xmm1
> 0xfffffd7ff9302561:     movsd  %xmm1,(%rsp)
> 0xfffffd7ff9302566:     mulsd  %xmm1,%xmm0
>
> (gdb) x/i 0xfffffd800066f690
> 0xfffffd800066f690:     Cannot access memory at address
> 0xfffffd800066f690
>
> (gdb) disassemble 0x66f690
> Dump of assembler code for function
> _ZN12ContextFrame13GetInt64ValueEPKS_ix:
> 0x000000000066f690 <_ZN12ContextFrame13GetInt64ValueEPKS_ix+0>: push
> %rbx
> 0x000000000066f691 <_ZN12ContextFrame13GetInt64ValueEPKS_ix+1>: sub
> $0x30,%rsp
> 0x000000000066f695 <_ZN12ContextFrame13GetInt64ValueEPKS_ix+5>: mov
> %rdi,0x18(%rsp)
> ...
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>




More information about the llvm-dev mailing list