<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Björn<br>
<br>
I think it would be helpful to provide some more of the assembly you
are ending up with. In the example below: Which source code are you
compiling? What does it try to achieve? What happens to eax, ebx,
rdi after the xor?<br>
<br>
+Andy,Zachary: Maybe you can correct, verify or explain in more
detail my analysis in the end of this mail. I have no internal
knowledge whatsoever, I just happened to reverse engineer this some
time ago.<br>
<br>
From what I found in the old thread and in your bug report, I can
make a guess.<br>
<p>
<blockquote type="cite">
<pre>I show you a short snippet of the assembly output.
mov eax, DWORD PTR ?myInt@@3HA ; myInt
lea rdi, OFFSET FLAT:__ImageBase
xor ebx, ebx
Then these offset is used to jump to some labels like "$<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">LL4 at execute</a>:".</pre>
</blockquote>
</p>
The $LL4 looks like a symbol name in a jump table. There are a few
examples (in the context of an unrelated bug report), that show how
such tables look like: <a class="moz-txt-link-freetext" href="https://gist.github.com/rygorous/6790191">https://gist.github.com/rygorous/6790191</a><br>
<br>
Here is an explanation of LEA:
<a class="moz-txt-link-freetext" href="https://stackoverflow.com/questions/1658294">https://stackoverflow.com/questions/1658294</a><br>
<br>
<br>
<div class="moz-cite-prefix">Am 22.03.18 um 18:43 schrieb Reid
Kleckner via llvm-dev:<br>
</div>
<blockquote type="cite"
cite="mid:CACs=tyJpq5DWUkrN=GR5rSAupPH8hNFB-dWwF0468YW8HB5j=Q@mail.gmail.com">
<div dir="ltr">I wouldn't be surprised if JITing COFF files on
Windows doesn't work so well, since the object file format
assumes most symbols are dllimport or within the local 2GB
module address range.</div>
</blockquote>
Reid gave an important hint here already: dllimport symbols. MSVC
apparently still assumes a small code model and uses 32 bit
relocations. (Maybe you could change that nowadays with a compiler
flag or so?)<br>
<br>
Have a look at this thread from 2015:
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/pipermail/llvm-dev/2015-November/092727.html">http://lists.llvm.org/pipermail/llvm-dev/2015-November/092727.html</a><br>
Quoting Andy Ayers:
<p>
<blockquote type="cite">
<pre>If at link time it turns out your export is from a DLL the linker will insert a jump stub / dllimport into the image for you which can handle larger distances.</pre>
</blockquote>
</p>
I guess this is the missing piece in your case. You have to do this
patching step yourself, that would otherwise happen magically in the
Microsoft linker (resolve relocation to a load-time jump stub) and
loader (create/fill jump stub with the actual DLL symbol address),
because the MSVC compiler assumes it when creating your obj file
(creates the relocation for a base address, adds the offset and
calls it). If this is the case, you should encounter __imp_foo
symbol relocations. I don't remember the exact details, but this is
what you want to watch out for.<br>
<br>
What needs to happen, conceptually, is something like this:
__ImageBase is the address of a table that you create and OFFSET
FLAT is a relative offset to the entry that you need to prepare. The
entry must NOT store the target addresses (to be loaded and called),
BUT a jump stub/trampoline like "jmp 0x00000000" (which forwards
execution to the actual call target).<br>
<br>
When you resolve the relocation for the import symbol (__imp_foo) to
the jump stub, you probably don't know the jmp target right away.
So, you can leave it nulled and emit a new relocation to fill out
the address (symbol foo). Depending on how your stub works, it may
be a relative offset or a 64-bit absolute address. In the end your
code calls the jump stub address as if it was the actual target
function. IIRC you cannot simply resolve the original relocation to
the target, even if you know it already, because the code emitted by
MSVC has the base+offset calculation already built in.<br>
<br>
There are some pretty useful tools for all that in LLVM Orc:<br>
<a class="moz-txt-link-freetext" href="https://github.com/llvm-mirror/llvm/blob/master/lib/ExecutionEngine/Orc/IndirectionUtils.cpp">https://github.com/llvm-mirror/llvm/blob/master/lib/ExecutionEngine/Orc/IndirectionUtils.cpp</a><br>
<br>
Cheers<br>
Stefan<br>
<br>
<div class="moz-cite-prefix">Am 13.12.18 um 07:59 schrieb Gaier,
Bjoern via llvm-dev:<br>
</div>
<blockquote type="cite"
cite="mid:OSAPR01MB317172FFC7828B615D7AFEF7E2A00@OSAPR01MB3171.jpnprd01.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">Hello everyone,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I’m using the LLVM for a JIT-Client under
Windows 64bit. I tried various stuff with it and noticed, that
object files or libraries which are generated by the Visual
Studio Compiler 2015 or 2017 will break the jitted code, when
they are added to the process.<o:p></o:p></p>
<p class="MsoNormal">I opened a bug for this a while ago (<a
href="https://bugs.llvm.org/show_bug.cgi?id=39447"
moz-do-not-send="true">https://bugs.llvm.org/show_bug.cgi?id=39447</a>)
– sadly this bug will become a stopper for me… So I wanted to
ask for advice:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Does anyone know anything about this bug or
a similar one? Does anyone have an idea about this? Is this
bug maybe a duplication with another bug?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I’m still a beginner, so I hope I did
everything right >o<<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Kind greetings<o:p></o:p></p>
<p class="MsoNormal">Björn<o:p></o:p></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, Takeshi Fukushima. Junichi Tajika
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="https://weliveindetail.github.io/blog/">https://weliveindetail.github.io/blog/</a>
<a class="moz-txt-link-freetext" href="https://cryptup.org/pub/stefan.graenitz@gmail.com">https://cryptup.org/pub/stefan.graenitz@gmail.com</a></pre>
</body>
</html>