<div dir="rtl"><div dir="ltr">If it's a Windows-only thing the correct tests would be:</div><div dir="ltr"><div dir="ltr"><br></div><div dir="ltr"><font face="courier new, monospace"> if (NumBytes >= 4096 && STI.isOSWindows()) {</font></div>
<div><br></div><div>and</div><div><br></div><div><div><font face="courier new, monospace"> if (Subtarget->isTargetWindows())</font></div></div><div><br></div></div><div dir="ltr">where </div><div dir="ltr"><br></div>
<div dir="ltr">
<div dir="ltr"><font face="courier new, monospace"> bool isOSWindows() const { return TargetTriple.isOSWindows(); }</font></div><div><br></div><div>Yaron</div><div><br></div></div></div><div class="gmail_extra"><div dir="ltr">
<br><br><div class="gmail_quote">2013/10/23 Andrew MacPherson <span dir="ltr"><<a href="mailto:andrew.macp@gmail.com" target="_blank">andrew.macp@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 .8ex;border-left:1px #ccc solid;border-right:1px #ccc solid;padding-left:1ex;padding-right:1ex">
<div><div>Glad that helped! As I understand it __chkstk is always required on Windows regardless of output type, I had meant to file a bug about this but had apparently forgotten to do so. I think the check needs to be that the target is Windows and ignore the output type, Linux and OSX don't use this.<br>
<br></div>Cheers,<br></div>Andrew<br></blockquote></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 23, 2013 at 11:32 AM, Yaron Keren <span dir="ltr"><<a href="mailto:yaron.keren@gmail.com" target="_blank">yaron.keren@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="rtl"><div dir="ltr">YES, this is the problem! </div><div dir="ltr"><br></div><div dir="ltr">The program work ok, even a 5x larger version works well.</div>
<div dir="ltr"><br></div><div dir="ltr">Clearly the _chkstk calls must be emitted with ELF target on Windows as well - why not?</div>
<div dir="ltr"><br></div><div dir="ltr">I'd like to make a patch and fix this right.</div><div dir="ltr"><br></div><div dir="ltr">I experimented with both changes and practically only the lib/Target/X86/X86ISelLowering.cpp fixes the problem. The other change lib/Target/X86/X86FrameLowering.cpp was not required to fix the problem thus it is probably required for other reasons. </div>
<div dir="ltr"><br></div><div dir="ltr">So, should I patch both tests?</div><div dir="ltr">Is the correct patch removing the test isTargetCOFF() completely?</div><div dir="ltr">Or enabling it for both COFF or ELF tarrgets?</div>
<div dir="ltr">I mean - is there any X86 target that does NOT require this stack checking?</div><span><font color="#888888"><div dir="ltr"><br></div><div dir="ltr">Yaron</div><div dir="ltr"><br></div></font></span></div>
<div><div><div class="gmail_extra"><div dir="ltr"><br>
<br><div class="gmail_quote">2013/10/23 Andrew MacPherson <span dir="ltr"><<a href="mailto:andrew.macp@gmail.com" target="_blank">andrew.macp@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 .8ex;border-left:1px #ccc solid;border-right:1px #ccc solid;padding-left:1ex;padding-right:1ex">
<div>Hi Yaron,<br><br></div>If you're outputting ELF on Windows this sounds like an issue we ran into where __chkstk calls weren't being output in the assembly due to an explicit check for COFF output. Once stack allocations in a given function exceeded some amount we'd get exactly this kind of crash in the function initialization.<br>
<br>If you take a look for isTargetCOFF() in lib/Target/X86/X86ISelLowering.cpp and lib/Target/X86/X86FrameLowering.cpp you should be able to remove that check to force __chkstk output to see if that helps.<br><br>Cheers,<br>
Andrew<br>
</blockquote></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Wed, Oct 23, 2013 at 1:22 AM, Yaron Keren <span dir="ltr"><<a href="mailto:yaron.keren@gmail.com" target="_blank">yaron.keren@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="rtl"><div dir="ltr">Yes, this is correct code address accessing bad data address.</div>
<div dir="ltr"><br></div>
<div dir="ltr">However, there is no other relocation before .text or near it. I'll send you the full debug printout, maybe you'll note something.</div>
<div dir="ltr"><br></div><div dir="ltr">The problem could be result of something else entirely else than the linker such as some library initialization code that by chance worked with smaller code but fails now.</div><div dir="ltr">
<br></div><div dir="ltr">I need to debug and see what's going on. The trouble is no debug information. Maybe I can do without the source code information and debug the assembly but without any symbols it's really a challenge to understand anything. I did try to make MCJIT emit debug info but for some reason attached gdb did not understand it. Maybe this could be solved.</div>
<div dir="ltr"><br></div><div dir="ltr">I assumed there may be some limitations around 31-32 bits as there are various int32 members in the ELF structure, but that's far far away. Problems start at .text size of about 150K.</div>
<span><font color="#888888">
<div dir="ltr"><br></div><div dir="ltr">Yaron</div><div dir="ltr"><br></div><div dir="ltr"><br></div></font></span></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote"><div dir="ltr">
2013/10/22 Kaylor, Andrew <span dir="ltr"><<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>></span></div>
<blockquote class="gmail_quote" style="margin:0 .8ex;border-left:1px #ccc solid;border-right:1px #ccc solid;padding-left:1ex;padding-right:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">So it looks like 0x0A3600D1 is a good code address and there’s no problem executing the code there, but 0x00BC7680 is a bad data address. Is that correct?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">If so, this is almost certainly a relocation problem. You just need to find a relocation that writes an entry (probably a relative offset) at 0x0A3600D1+the
size of the instruction at that address.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">BTW, what I said before about not being aware of any size limitations wasn’t quite correct. If you have enough code and data that we end up putting sections
at addresses that are more than 2GB apart we’ll have problems, but you should see an assertion in that case. That can happen if we weren’t able to get the address we requested from allocateMappedMemory, but it doesn’t look like that’s what’s happening here.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">-Andy<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Yaron Keren [mailto:<a href="mailto:yaron.keren@gmail.com" target="_blank">yaron.keren@gmail.com</a>]
<br>
<b>Sent:</b> Tuesday, October 22, 2013 1:41 PM</span></p><div><div><br>
<b>To:</b> Kaylor, Andrew<br>
<b>Cc:</b> <<a href="mailto:llvmdev@cs.uiuc.edu" target="_blank">llvmdev@cs.uiuc.edu</a>><br>
<b>Subject:</b> Re: Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen?<u></u><u></u></div></div><p></p><div><div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">Hi,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks for your ideas.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Memory allocation already exceeds 2x64K in the "working" case so it's not the condition of allocating more than 64K. To be sure I had modified SectionMemoryManager::allocateSection to allocate four time the required memory but it did not
trigger more crashes.I debugged through the allocation code including the Win32 code and it seems to work well. I have also tried disabling the MemGroup.FreeMem cache which did not matter.<u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">An added assert for no Stubs to the end of RuntimeDyldImpl::loadObject<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New""> processRelocationRef(SectionID, *i, *obj, LocalSections, LocalSymbols,</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New""> Stubs);</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New""> assert(!Stubs.size());</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">indeed caught nothing = no stubs created.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Disabling (de)registerEH did not help.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Looking at relocations and sections printouts, the exception is:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New"">Unhandled exception at 0x0A3600D1 :</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New"">0xC0000005: Access violation writing location 0x00BC7680.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">which is right after the start of .text:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New"">emitSection SectionID: 1 Name: .text obj addr: 0A3F1350 new addr: 0A360000 DataSize: 253203 StubBufSize: 0 Allocate: 253203</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New"">...</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New"">Resolving relocations Section #1 0A360000</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">so at least it is running code but tries to write a wrong location.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Another run exhibits similar crash, still in .text but somewhat later.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I have checked and the function address I'm running is located in .text towards the end, as expected since it's the last function added to the Module.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Also I speculated that if it crashes when .text crosses 128K but no, it happens when it's larger.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I had attached gdb to the process hoping it will show more information but it showed even less information than the Visual C++ debugger.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Out of ideas... <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Yaron<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">2013/10/22 Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>><u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-left:solid #cccccc 1.0pt;border-bottom:none;border-right:solid #cccccc 1.0pt;padding:0in 6.0pt 0in 6.0pt;margin-left:4.8pt;margin-right:4.8pt">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I would guess that it’s crashing somewhere in the generated code. On Windows we don’t have a way
to get call stacks to the generated code (though if you want to try it on Linux, that should work). You can probably look at the address where the crash is occurring and verify that it is in the generated code.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">There are a couple of things I would look for.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">First, I’d take a look at the SectionMemoryManager allocation handling. The fact that the problem
is code size dependent strongly points in this direction. It may be that SectionMemoryManager does something wrong when it hits a page boundary or something.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Second, I’d look at the relocation processing. If it is generating any stubs, that would be a potential
problem spot, but it shouldn’t be generating any stubs. So the obvious thing to look at is whether any of the relocations are writing to the spot where the crash occurs.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">-Andy</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Yaron Keren [mailto:<a href="mailto:yaron.keren@gmail.com" target="_blank">yaron.keren@gmail.com</a>]
<br>
<b>Sent:</b> Tuesday, October 22, 2013 10:17 AM<br>
<b>To:</b> Kaylor, Andrew<br>
<b>Cc:</b> <<a href="mailto:llvmdev@cs.uiuc.edu" target="_blank">llvmdev@cs.uiuc.edu</a>><br>
<b>Subject:</b> Re: Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen?</span><u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">OS is Windows 7 64 bit OS, compiler is 32 bit Visual C++ 2012 with 32 bit.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">The target which is i686-pc-mingw32-elf so I can use the ELF dynamic loader. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Code model, relocation model and and memory manager are whatever default for this - did not modify.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">The Module comes from clang. The source is 1000 or more lines repeating C++ code in one big function:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New""> A+1;</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New""> A*B.t();</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">where A and B are matrices from Armadillo <a href="http://arma.sourceforge.net/" target="_blank">http://arma.sourceforge.net/</a>. This a stress and performance test due to the
large number of EH and temporary objects created.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal">I am using the Engine Builder and MCJIT unmodified (except the multi-modules patches which are not relevant as there is only one module) like this:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New""> OwningPtr<llvm::ExecutionEngine> EE(llvm::EngineBuilder(M)</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New""> .setErrorStr(&Error)</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New""> .setUseMCJIT(true)</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New""> .create());</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">to run the function either <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New""> llvm::Function *F = M->getFunction(Name);</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New""> void *FN = EE->getPointerToFunction(F);</span><u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal">or<u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New""> uint64_t FN = EE->getFunctionAddress(Name);</span><u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">followed by <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New""> ((void (*)())FN)();</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">or<u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New""> EE->runFunction(F, std::vector<llvm::GenericValue>());</span><u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">all work the same with smaller about 1000 lines of the above code module and crash the same with more code. The call stack is unhelpful Visual C++ says: Frames below may be incorrect
and/or missing which indicates a real problem with it. I have tried to provide less stack space (default is 10M) for the compiled program without any change.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Yaron<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal" dir="RTL" style="margin-bottom:12.0pt;text-align:right;direction:rtl">
<span dir="LTR"> <u></u><u></u></span></p>
<div>
<div>
<p class="MsoNormal">2013/10/22 Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>><span dir="RTL" lang="AR-SA"><u></u><u></u></span></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" dir="RTL" style="text-align:right;direction:rtl">
<span dir="LTR" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I’m not aware of such a limitation</span><span dir="RTL"></span><span style="font-size:11.0pt;color:#1f497d" lang="AR-SA"><span dir="RTL"></span>.</span><span dir="LTR"><u></u><u></u></span></p>
<p class="MsoNormal" dir="RTL" style="text-align:right;direction:rtl">
<span dir="RTL"></span><span style="font-size:11.0pt;color:#1f497d" lang="AR-SA"><span dir="RTL"></span> </span><span lang="AR-SA"><u></u><u></u></span></p>
<p class="MsoNormal" dir="RTL" style="text-align:right;direction:rtl">
<span dir="LTR" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">What architecture, code model and relocation model are you using</span><span dir="RTL"></span><span style="font-size:11.0pt;color:#1f497d" lang="AR-SA"><span dir="RTL"></span>?
</span><span dir="LTR" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Are you using the SectionMemoryManager</span><span dir="RTL"></span><span style="font-size:11.0pt;color:#1f497d" lang="AR-SA"><span dir="RTL"></span>?</span><span lang="AR-SA"><u></u><u></u></span></p>
<p class="MsoNormal" dir="RTL" style="text-align:right;direction:rtl">
<span style="font-size:11.0pt;color:#1f497d" lang="AR-SA"> </span><span lang="AR-SA"><u></u><u></u></span></p>
<p class="MsoNormal" dir="RTL" style="text-align:right;direction:rtl">
<span style="font-size:11.0pt;color:#1f497d" lang="AR-SA">-</span><span dir="LTR" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Andy</span><span lang="AR-SA"><u></u><u></u></span></p>
<p class="MsoNormal" dir="RTL" style="text-align:right;direction:rtl">
<span style="font-size:11.0pt;color:#1f497d" lang="AR-SA"> </span><span lang="AR-SA"><u></u><u></u></span></p>
<p class="MsoNormal" dir="RTL" style="text-align:right;direction:rtl">
<b><span dir="LTR" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From</span></b><span dir="RTL"></span><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" lang="AR-SA"><span dir="RTL"></span>:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" lang="AR-SA">
</span><span dir="LTR" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">Yaron Keren [mailto</span><span dir="RTL"></span><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" lang="AR-SA"><span dir="RTL"></span>:<a href="mailto:yaron.keren@gmail.com" target="_blank"><span dir="LTR" lang="EN-US">yaron.keren@gmail.com</span></a><span dir="RTL"></span><span dir="RTL"></span>]
<br>
</span><b><span dir="LTR" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">Sent</span></b><span dir="RTL"></span><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" lang="AR-SA"><span dir="RTL"></span>:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" lang="AR-SA">
</span><span dir="LTR" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">Tuesday, October 22, 2013 8:12 AM</span><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" lang="AR-SA"><br>
</span><b><span dir="LTR" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">To</span></b><span dir="RTL"></span><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" lang="AR-SA"><span dir="RTL"></span>:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" lang="AR-SA">
<<a href="mailto:llvmdev@cs.uiuc.edu" target="_blank"><span dir="LTR" lang="EN-US">llvmdev@cs.uiuc.edu</span></a><span dir="RTL"></span><span dir="RTL"></span>>;
</span><span dir="LTR" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">Kaylor, Andrew</span><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" lang="AR-SA"><br>
</span><b><span dir="LTR" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">Subject</span></b><span dir="RTL"></span><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" lang="AR-SA"><span dir="RTL"></span>:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" lang="AR-SA">
</span><span dir="LTR" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen</span><span dir="RTL"></span><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" lang="AR-SA"><span dir="RTL"></span>?</span><span lang="AR-SA"><u></u><u></u></span></p>
<div>
<div>
<p class="MsoNormal" dir="RTL" style="text-align:right;direction:rtl">
<span lang="AR-SA"> <u></u><u></u></span></p>
<div>
<div>
<p class="MsoNormal" dir="RTL" style="text-align:right;direction:rtl">
<span dir="LTR">I'm running in MCJIT a module generated from one C</span><span dir="RTL"></span><span lang="AR-SA"><span dir="RTL"></span>++
</span><span dir="LTR">function. Every line of the source function uses C</span><span dir="RTL"></span><span lang="AR-SA"><span dir="RTL"></span>++
</span><span dir="LTR">classes and may throw an exception. As long as there are less than (about) 1000 lines, everything works. With more lines the compiled</span><span dir="RTL"></span><span dir="RTL"></span>
<span dir="LTR">code crashes when running it, with no sensible stack trace</span><span dir="RTL"></span><span lang="AR-SA"><span dir="RTL"></span>.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" dir="RTL" style="text-align:right;direction:rtl">
<span lang="AR-SA"> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" dir="RTL" style="text-align:right;direction:rtl">
<span dir="LTR">Is there any kind of hard-coded size limitation in</span><span dir="RTL"></span><span lang="AR-SA"><span dir="RTL"></span> </span><span dir="LTR">MCJIT / ELF Dynamic Linker / ELF codegen / number of EH states in a function</span><span dir="RTL"></span><span lang="AR-SA"><span dir="RTL"></span>
? <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" dir="RTL" style="text-align:right;direction:rtl">
<span lang="AR-SA"> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" dir="RTL" style="text-align:right;direction:rtl">
<span dir="LTR">I did browse the code but could not find anything obvious</span><span dir="RTL"></span><span lang="AR-SA"><span dir="RTL"></span>. <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" dir="RTL" style="text-align:right;direction:rtl">
<span lang="AR-SA"> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" dir="RTL" style="text-align:right;direction:rtl">
<span dir="LTR">Yaron</span><span lang="AR-SA"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" dir="RTL" style="text-align:right;direction:rtl">
<span lang="AR-SA"> <u></u><u></u></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal" dir="RTL" style="text-align:right;direction:rtl">
<span lang="AR-SA"> <u></u><u></u></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><span dir="RTL" lang="AR-SA"><u></u> <u></u></span></p>
</div>
</div></div></div>
</div>
</blockquote></div><br></div>
</div></div><br></div></div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div></div></div>
</div></div></blockquote></div><br></div>
</div></div></div></div>