[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