llvm dev - Dec 2009 - [LLVMdev] 2.6 JIT using wrong address for external functions

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)
...

hi Nathan,
> 
> This has been working for about two months and I can't readily figure
> out what I changed to break it.
> 

have you recently upgraded from version 2.5 to 2.6?
maybe it's related to my bugzilla PR 3666.

tobias

I upgraded a while back but recently did a clean rebuild of my project
at -O3... so it is possible I was inadvertently pulling in an older
pre-2.6 lib before (back when it was working).

Do you know of any workarounds to try? I don't have full symbols in the
LLVM libs so debugging is a bit of a pain.

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On Behalf Of Tobias
Sent: Monday, December 07, 2009 10:22 AM
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] 2.6 JIT using wrong address for external
functions

hi Nathan,
> 
> This has been working for about two months and I can't readily figure
> out what I changed to break it.
> 

have you recently upgraded from version 2.5 to 2.6?
maybe it's related to my bugzilla PR 3666.

tobias

_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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
>

Enabling the lazy JIT worked for now... since my functions are always
fully inlined. I'll upgrade to ToT next time I'm feeling adventurous :-)

Thanks Jeffrey.

-----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 external
functions

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.