<div dir="ltr"><div><div><div><div><div>Thanks for your answers.<br></div><div><br>First of all I made mistake saying that R_X86_64_PC32 relocations are used only within .eh_frame section in my case. Calls to __chkstk routine are resolved with R_X86_64_PC32 relocations. <br>
Here is the quote from applied to my elf-file llvm-objdump -r output:<br><br>349485 R_X86_64_64 .rodata.str1.16+6000<br>349518 R_X86_64_64 __CHECK_DINT_RANGE__@CRT+0<br>349605 R_X86_64_64 memcpy+0<br>349671 R_X86_64_PC32 __chkstk-4-P<br>
349691 R_X86_64_64 memcpy+0<br>349701 R_X86_64_64 .rodata+4400<br>349800 R_X86_64_64 .rodata.str1.16+6048<br><br></div>Corresponding assembly output for this __chkstk call:<br><br>.Ltmp4202:<br> .cfi_def_cfa_offset 72<br>
movabs rax, 4216<br> call __chkstk<br> sub rsp, rax<br><br></div>For example, memcpy is called indirectly:<br><br> movabs rax, memcpy<br> movabs rdx, .L.cdata421770<br> mov r8d, 2308<br>
call rax<br><br></div><br><span id="result_box" class="" lang="en"><span class=""><span id="result_box" class="" lang="en"><span class="">In my case,</span> <span class="">the calculated</span> <span class="">distance to the</span> <span class="">__chkstk</span> <span class="">does not fit into 32bit</span><span class="">.</span></span> This is observed under Windows 8.1 only. I found the</span> <span class="">discussion of </span></span><span id="result_box" class="" lang="en"><span class="">__chkstk/Win64 issue: <a href="http://comments.gmane.org/gmane.comp.compilers.llvm.cvs/108361">http://comments.gmane.org/gmane.comp.compilers.llvm.cvs/108361</a>. But </span></span><span id="result_box" class="" lang="en"><span class="">I</span> <span class="">didn't understand</span> <span class="">why the problem</span> <span class="">was not fixed</span><span>,</span> <span class="">if it</span> <span class="">really is a bug</span><span class="">.<br>
<br></span></span></div><span id="result_box" class="" lang="en"><span class="">As for memory manager it behaves as Andrew said. It allocates memory blocks very nearly one to </span></span><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)"></span>another, so using of R_X86_64_PC32 relocations within .eh_frame section (inside one module) makes no problem.<br>
<br></div><div>That I also noticed, __chkstk is called in case when block size is 4216 bytes whereas Microsoft says (<a href="http://msdn.microsoft.com/en-us/library/ms648426%28v=vs.85%29.aspx">http://msdn.microsoft.com/en-us/library/ms648426%28v=vs.85%29.aspx</a>) about 8K limit of stack block size for using __chkstk.<br>
<br></div><div><br></div><div>Alexey<br></div><div><br></div><div><div><div><div><div><div><div><br></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-05-27 22:28 GMT+03:00 Kaylor, Andrew <span dir="ltr"><<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="white" link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I would think that the R_X86_64_PC32 relocation type should never be generated with large code model since large code model, by definition, makes no assumptions
about the size or address of sections. The use of win32-elf might throw a wrinkle into this, since that is a code path that probably isn’t exercised much outside of MCJIT use.<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">That said, when this assertion fails it is usually because of an implementation problem such as Philip describes.<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">In theory, when the memory manager allocates memory the address of any two blocks allocated can come back with arbitrarily distant addresses. The only way
to guarantee that the address of two sections will never be more than 2 GB apart is to allocate a single block to hold the memory for both sections. Some changes were proposed recently to allow this with custom memory managers, but I don’t know if the changes
have been committed.<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">In practice, unless some kind of address randomization tool is being used the default memory manager will allocate all blocks within close proximity to one
another very nearly all the time, particularly on x86-based Linux systems. As such, if you are seeing this kind of failure consistently it probably does mean that the sections in question got their addresses in different ways.<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">Can you reproduce the problem using lli or llvm-rtdyld?<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>
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext"> <a href="mailto:llvmdev-bounces@cs.uiuc.edu" target="_blank">llvmdev-bounces@cs.uiuc.edu</a> [mailto:<a href="mailto:llvmdev-bounces@cs.uiuc.edu" target="_blank">llvmdev-bounces@cs.uiuc.edu</a>]
<b>On Behalf Of </b>Philip Reames<br>
<b>Sent:</b> Monday, May 26, 2014 11:33 AM<br>
<b>To:</b> Aliaksei Zasenka; <a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a><br>
<b>Subject:</b> Re: [LLVMdev] Assertion fails resolving R_X86_64_PC32 relocation<u></u><u></u></span></p>
</div>
</div><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">I ran into a similar error a while back and it turned out to be user error on my part. I had relocated some of the sections in the object file, but not others. As a result, I'd ended up with one (unrelocated) section with a reference
to another (relocated) section which was more than 32 bits away. You may want to double check your memory layout. What caught my eye about your question was that ".eh_frame" was one of the sections in question for me too.
<br>
<br>
Philip<br>
<br>
On 05/26/2014 08:51 AM, Aliaksei Zasenka wrote:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Hi llvm-community,<u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">I use llc (3.4-final) to generate object file:<br>
<br>
<i>llc code.bc -mtriple=x86_64-pc-win32-elf -mcpu=x86-64 -filetype=obj -code-model=large -o=code.o</i><u></u><u></u></p>
</div>
<p class="MsoNormal">then I load it with <i>RuntimeDyld + SectionMemoryManager</i> in my app.<br>
<br>
I faced the problem described in <a href="http://llvm.org/bugs/show_bug.cgi?id=15356" target="_blank">
15356 </a>bug. Debug assertion fails at /lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:273.<br>
I noticed that R_X86_64_PC32 relocations are used only within .eh_frame section. Why aren't R_X86_64_64 relocations used in that case?
<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Is there any working solution of this problem?<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">Thank you in advance.<br>
<br>
--<br>
<span style="font-size:9.0pt;font-family:"Tahoma","sans-serif";color:#6b6b6b">Best regards,</span><u></u><u></u></p>
</div>
<p class="MsoNormal">Alexey Zasenko<u></u><u></u></p>
</div>
<p class="MsoNormal"><br>
<br>
<br>
<u></u><u></u></p>
<pre>_______________________________________________<u></u><u></u></pre>
<pre>LLVM Developers mailing list<u></u><u></u></pre>
<pre><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><u></u><u></u></pre>
<pre><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><u></u><u></u></pre>
</blockquote>
<p class="MsoNormal"><u></u> <u></u></p>
</div></div></div>
</div>
</blockquote></div><br></div>