<div dir="ltr"><div dir="ltr">Hi Stefan, Bjoern,<div><br></div><div>For calls across object boundaries __dllimport now supported in RuntimeDyld: <a href="https://github.com/llvm/llvm-project/commit/337e131ca7de48072def7729df69434c37a66eb7">https://github.com/llvm/llvm-project/commit/337e131ca7de48072def7729df69434c37a66eb7</a>. You may just be able to mark your externs as __dllimport for this to work. I don't recall whether __dllimport works for data symbols too, but I suspect so -- I think it's basically an explicit GOT entry.</div><div><br></div><div>If anyone is ever interested in writing a JITLink COFF implementation I will be happy to help out or review patches -- I'd love to get better COFF support in tree.</div><div><br></div><div>-- Lang.</div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 21, 2020 at 2:09 PM Stefan Gränitz <<a href="mailto:stefan.graenitz@gmail.com">stefan.graenitz@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div>
Hi Björn<br>
<br>
I made a workaround for this specific issue a long time ago for the
Projucer C++ JIT Engine. It basically forwards the call to another
stub that provides enough space to encode a full 64-bit address. The
patch is based on LLVM 3.9, so I guess it won't work out-of-the-box
on a recent release, but it may give you enough hints to figure it
out on your own:<br>
<a href="https://github.com/weliveindetail/pj-llvm/commit/97cd336d458ae9c73232d1b539ceefcdb2f5eb0f" target="_blank">https://github.com/weliveindetail/pj-llvm/commit/97cd336d458ae9c73232d1b539ceefcdb2f5eb0f</a><br>
<br>
Alternatively, you could consider a memory manager that makes sure
all calls are within a 32-bit range. For the code you JIT yourself,
this should be no problem. In case you have to link against an old
MSVCRT though, this is not possible, because it has a fixed load
address that's far beyond the 32-bit range from any heap allocation
you can make for your JITed code. That's been our issue back then
and so this patch was the last resort.<br>
<br>
Please also note: this is for freestanding function only. I didn't
consider member function calls, etc. (addend is always 0) because it
was not relevant for the specific issue.<br>
<br>
Hope it helps<br>
Stefan<br>
<br>
<div>On 21/08/2020 13:22, Gaier, Bjoern via
llvm-dev wrote:<br>
</div>
<blockquote type="cite">
<div>
<p class="MsoNormal"><span lang="EN-GB">I figured out that this
problem is caused because “planschiValue” has a REL32
relocation and the addresses between the code and the
variable overflows 32bit.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">Is there any workaround
for this kind of issue?<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<div>
<div style="border-style:solid none none;border-top-width:1pt;border-top-color:rgb(225,225,225);padding:3pt 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> llvm-dev
<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank"><llvm-dev-bounces@lists.llvm.org></a>
<b>On Behalf Of </b>Gaier, Bjoern via llvm-dev<br>
<b>Sent:</b> 20 August 2020 12:15<br>
<b>To:</b> LLVM Developers Mailing List
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank"><llvm-dev@lists.llvm.org></a>; Lang Hames
<a href="mailto:lhames@gmail.com" target="_blank"><lhames@gmail.com></a><br>
<b>Subject:</b> [llvm-dev] ORC JIT - Incorrect support
for COFF files?<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><span lang="EN-GB">Hey LLVM-Mailing-List
and Lang,<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">I’m still learning how
to use the ORC JIT but I finally reached the point to JIT
and execute some code. For this purpose I created a test
file (TestModule.cpp) and compiled it with Clang, generating
two different files, one in the LLVM IR format and one in
the Microsoft COFF format.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<p class="MsoNormal" style="margin-bottom:12pt"><span lang="EN-GB">The JIT resolves all undefined references,
including “</span><span style="font-size:9.5pt;font-family:Consolas;color:blue" lang="EN-GB">extern</span><span style="font-size:9.5pt;font-family:Consolas;color:black" lang="EN-GB">
</span><span style="font-size:9.5pt;font-family:Consolas;color:blue" lang="EN-GB">int</span><span style="font-size:9.5pt;font-family:Consolas;color:black" lang="EN-GB"> planschiValue;</span><span lang="EN-GB">” and
“</span><span style="font-size:9.5pt;font-family:Consolas;color:blue" lang="EN-GB">void</span><span style="font-size:9.5pt;font-family:Consolas;color:black" lang="EN-GB"> externFunction();</span><span lang="EN-GB">”.
Using the IR Module I will get the correct address for
“planschiValue” and the correct value – however this is not
the case for the object file.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">For the object file I get (via printf from the
module) the address 0x000002295D6B003C while the actual
address is 0x00007FF71D9959A4.
<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">I’m really surprised about this, because the IR
module works with no problem. I attach the source code, the
IR file and the resulting object file (including its
assembly file).<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">Any ideas what I’m doing wrong?<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">Thank you for the help in advance and kind
greetings<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">Björn<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<p class="MsoNormal"><span>Als
GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB
9816, USt.ID-Nr. DE 114 165 789 Geschäftsführer: Dr. Hiroshi
Nakamura, Dr. Robert Plank, Markus Bode, Heiko Lampert,
Takashi Nagano, Junichi Tajika, Ergin Cansiz. <u></u><u></u></span></p>
</div>
Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB
9816, USt.ID-Nr. DE 114 165 789 Geschäftsführer: Dr. Hiroshi
Nakamura, Dr. Robert Plank, Markus Bode, Heiko Lampert, Takashi
Nagano, Junichi Tajika, Ergin Cansiz.
<br>
<fieldset></fieldset>
<pre>_______________________________________________
LLVM Developers mailing list
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<pre cols="72">--
<a href="https://flowcrypt.com/pub/stefan.graenitz@gmail.com" target="_blank">https://flowcrypt.com/pub/stefan.graenitz@gmail.com</a></pre>
</div>
</blockquote></div>