[LLVMdev] A weird, reproducable problem with MCJIT

Kaylor, Andrew andrew.kaylor at intel.com
Tue Oct 15 14:48:31 PDT 2013


This issue should be fixed in r192737.

I moved the getMaxStubSize and getStubAlignment functions into the RuntimeDyldELF and RuntimeDyldMachO classes since the code that generates the stubs is specific to those classes and a difference between them is what led to this problem.

In the case of RuntimeDyldMachO I removed the stub size handling for architectures that are not currently handled in that class because I thought it would be best not to have artifacts that might seem to be correct (but possibly weren't) hanging around if someone later added support for one of these architectures.

-Andy

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Christian Schafmeister
Sent: Tuesday, October 15, 2013 8:11 AM
To: llvmdev at cs.uiuc.edu
Subject: Re: [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

_______________________________________________
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