thr3ads.net - llvm dev - [LLVMdev] A weird, reproducable problem with MCJIT [Oct 2013]

If this information is useful, please help other people find it:
Share via:

Yaron Keren

2013-Oct-15 04:08 UTC

[LLVMdev] A weird, reproducable problem with MCJIT

Correct or no I don't know, but this change will affect all x86-64 targets
including Linux and Windows as getMaxStubSize() is called from the ELF
linker as well as the Mach-O linker.



2013/10/15 Christian Schafmeister <chris.schaf at verizon.net>
>
> With the help of iain at codesourcery.com and andrew.kaylor at intel.com we
> tracked the problem down to a bad relocation that was clobbering the
> first bytes of the eh_frame.   I think this problem/solution may be OS X
> specific.
>
> On akaylor's suggestion I made the change below and my reproducable
test
> case now compiles fine with MCJIT.
>
> As well, my Common Lisp code base now compiles using MCJIT - that's
about
> 1,000
> functions at one MCJIT module per function.
>
>
>
> In llvm/lib/ExecutionEngine/RuntimeDyld
>
> Index: RuntimeDyldImpl.h
> ==================================================================> ---
RuntimeDyldImpl.h   (revision 192535)
> +++ RuntimeDyldImpl.h   (working copy)
> @@ -195,7 +195,7 @@
>      else if (Arch == Triple::ppc64 || Arch == Triple::ppc64le)
>        return 44;
>      else if (Arch == Triple::x86_64)
> -      return 6; // 2-byte jmp instruction + 32-bit relative address
> +       return 8; /* was 6 but akaylor said change to 8 - meister Oct 2013
> */ // 2-byte jmp instruction + 32-bit relative address
>      else if (Arch == Triple::systemz)
>        return 16;
>      else
>
> _______________________________________________
> 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/20131015/837b0e1c/attachment.html>

Kaylor, Andrew

2013-Oct-15 15:01 UTC

head link

[LLVMdev] A weird, reproducable problem with MCJIT

Yes, you are correct Yaron.  Before we commit this we ought to put a check in to
see what the target OS is.  I just suggested the change below as a quick and
easy way to verify that this was the cause of the problem.  I'll clean it
up.

-Andy

From: Yaron Keren [mailto:yaron.keren at gmail.com]
Sent: Monday, October 14, 2013 9:09 PM
To: Christian Schafmeister; Kaylor, Andrew; iain at codesourcery.com
Cc: <llvmdev at cs.uiuc.edu>
Subject: Re: [LLVMdev] A weird, reproducable problem with MCJIT

Correct or no I don't know, but this change will affect all x86-64 targets
including Linux and Windows as getMaxStubSize() is called from the ELF linker as
well as the Mach-O linker.

2013/10/15 Christian Schafmeister <chris.schaf at
verizon.net<mailto:chris.schaf at verizon.net>>

With the help of iain at codesourcery.com<mailto:iain at codesourcery.com>
and andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com> we
tracked the problem down to a bad relocation that was clobbering the
first bytes of the eh_frame.   I think this problem/solution may be OS X
specific.

On akaylor's suggestion I made the change below and my reproducable test
case now compiles fine with MCJIT.

As well, my Common Lisp code base now compiles using MCJIT - that's about
1,000
functions at one MCJIT module per function.

In llvm/lib/ExecutionEngine/RuntimeDyld

Index: RuntimeDyldImpl.h
==================================================================---
RuntimeDyldImpl.h   (revision 192535)
+++ RuntimeDyldImpl.h   (working copy)
@@ -195,7 +195,7 @@
     else if (Arch == Triple::ppc64 || Arch == Triple::ppc64le)
       return 44;
     else if (Arch == Triple::x86_64)
-      return 6; // 2-byte jmp instruction + 32-bit relative address
+       return 8; /* was 6 but akaylor said change to 8 - meister Oct 2013 */ //
2-byte jmp instruction + 32-bit relative address
     else if (Arch == Triple::systemz)
       return 16;
     else

_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu<mailto: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/20131015/d7e18412/attachment.html>

Christian Schafmeister

2013-Oct-15 15:11 UTC

head link

[LLVMdev] A weird, reproducable problem with MCJIT

If I spoke incorrectly about what systems this problem/change effects I
apologize. I'll leave it to Andrew to determine that.

Best,

.Chris.


"Kaylor, Andrew" <andrew.kaylor at intel.com> writes:
> Yes, you are correct Yaron.  Before we commit this we ought to put a
> check in to see what the target OS is.  I just suggested the change
> below as a quick and easy way to verify that this was the cause of the
> problem.  I’ll clean it up.
>
>  
>
> -Andy
>
>  
>
> From: Yaron Keren [mailto:yaron.keren at gmail.com] 
> Sent: Monday, October 14, 2013 9:09 PM
> To: Christian Schafmeister; Kaylor, Andrew; iain at codesourcery.com
> Cc: <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] A weird, reproducable problem with MCJIT
>
>  
>
> Correct or no I don't know, but this change will affect all x86-64
> targets including Linux and Windows as getMaxStubSize() is called from
> the ELF linker as well as the Mach-O linker.
>
>  
>
>  
>
> 2013/10/15 Christian Schafmeister <chris.schaf at verizon.net>
>
>     
>     With the help of iain at codesourcery.com and andrew.kaylor at
intel.com
>     we
>     tracked the problem down to a bad relocation that was clobbering
>     the
>     first bytes of the eh_frame.   I think this problem/solution may
>     be OS X
>     specific.
>     
>     On akaylor's suggestion I made the change below and my
>     reproducable test
>     case now compiles fine with MCJIT.
>     
>     As well, my Common Lisp code base now compiles using MCJIT - that's
>     about 1,000
>     functions at one MCJIT module per function.
>     
>     
>     
>     In llvm/lib/ExecutionEngine/RuntimeDyld
>     
>     Index: RuntimeDyldImpl.h
>     ==================================================================> 
--- RuntimeDyldImpl.h   (revision 192535)
>     +++ RuntimeDyldImpl.h   (working copy)
>     @@ -195,7 +195,7 @@
>          else if (Arch == Triple::ppc64 || Arch == Triple::ppc64le)
>            return 44;
>          else if (Arch == Triple::x86_64)
>     -      return 6; // 2-byte jmp instruction + 32-bit relative
>     address
>     +       return 8; /* was 6 but akaylor said change to 8 - meister
>     Oct 2013 */ // 2-byte jmp instruction + 32-bit relative address
>          else if (Arch == Triple::systemz)
>            return 16;
>          else
>
>     
>     
>         
>     _______________________________________________
>     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

Maybe Matching Threads

Search for more seemingly similar threads

llvm dev - Oct 2013 - [LLVMdev] A weird, reproducable problem with MCJIT

[LLVMdev] A weird, reproducable problem with MCJIT

[LLVMdev] A weird, reproducable problem with MCJIT

[LLVMdev] A weird, reproducable problem with MCJIT

Maybe Matching Threads