<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 09/18/2014 10:17 AM, Lang Hames
wrote:<br>
</div>
<blockquote
cite="mid:CALLttgrVi5YjnOwn_YV+m=BG6spiCAbZ64UUKgXt+VfYqhx2vA@mail.gmail.com"
type="cite">
<div dir="ltr">Hi Matt, Philip,
<div><br>
</div>
<div>You could get the data you want by recording the addresses
returned by the allocateCodeSection and allocateDataSection
methods on your RTDyldMemoryManager, then disassembling those
sections after you've called resolveRelocations. That's a
little unsatisfying though. For one thing, unless you very
carefully maintain the association with the original object
via back-channels there will be no way of knowing which
section belongs to which object file.</div>
</div>
</blockquote>
I know. This is what I'm actually doing today. :)<br>
<blockquote
cite="mid:CALLttgrVi5YjnOwn_YV+m=BG6spiCAbZ64UUKgXt+VfYqhx2vA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>With a bit of cleanup though, we could do something more
like this:</div>
<div><br>
</div>
<div><font face="courier new, monospace">const
RuntimeDyld::JITObject& JO = RTDyld.loadObject(Object);</font></div>
<div><font face="courier new, monospace">// ...</font></div>
<div><font face="courier new, monospace">RTDyld.resolveRelocations();</font></div>
<div><font face="courier new, monospace"><br>
</font></div>
<div><font face="courier new, monospace">DEBUG(</font></div>
<div><font face="courier new, monospace"> for (const
RuntimeDyld::JITObject::Section& S : JO.sections())</font></div>
<div><font face="courier new, monospace"> if (S.isText())</font></div>
<div><font face="courier new, monospace">
Disassemble(S.getAddr(), S.getSize());</font></div>
<div><font face="courier new, monospace">);</font></div>
<div><br>
</div>
<div>How does that look?</div>
</div>
</blockquote>
I'm not using the loadObject interface today. On the surface, this
looks ideal, but I don't have any practical experience to confirm.
I'm currently using the interfaces on ExecutionEngine (i.e.
generateCodeForModule, mapSectionAddress, finalizeObject, then
getPointerToFunction)<br>
<blockquote
cite="mid:CALLttgrVi5YjnOwn_YV+m=BG6spiCAbZ64UUKgXt+VfYqhx2vA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Cheers,</div>
<div>Lang.</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Sep 17, 2014 at 3:08 PM, Philip
Reames <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class=""><br>
On 09/17/2014 12:45 PM, Matt Godbolt wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Great stuff; thanks both!<br>
<br>
I'm also looking to turn my MCJIT conversion spike into
our main use<br>
case. The only thing I'm missing is the ability to get a
post-linked<br>
copy of the generated assembly.<br>
<br>
In JIT I used JITEventListener's NotifyFunctionEmitted
and used a<br>
MCDisassembler to disassemble the stream (with my own
custom<br>
annotators), and redirected the output to the relevant
place for<br>
auditing of our app.<br>
<br>
With MCJIT I notice that NotifyFunctionEmitted is gone<br>
(understandably) and so I hook NotifyObjectEmitted. I
then run through<br>
all the function symbols and dump them as before. Yay.
Except that in<br>
MCJIT terms the linking hasn't happened, so all the
globals and<br>
external functions are all zeros at this point. (If I
hackily observe<br>
the same code later on I see the linker has
appropriately populated<br>
these addresses). This makes my nicely annotated code a
little<br>
unreadable, unfortunately.<br>
<br>
Does anyone have any suggestions as to how I might get
to disassemble<br>
the post-linked code?<br>
</blockquote>
</span>
my 2 cents: It seems like we need a different event type.
Having access to the object before linking (and relocation?)
seems useful, but I suspect most users (myself included)
want the final object after everything is done.<span
class="HOEnZb"><font color="#888888"><br>
<br>
Philip</font></span>
<div class="HOEnZb">
<div class="h5"><br>
<br>
On Wed, Sep 17, 2014 at 2:35 PM, Yaron Keren <<a
moz-do-not-send="true"
href="mailto:yaron.keren@gmail.com" target="_blank">yaron.keren@gmail.com</a>>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
You need to call llvm::sys::getHostCPUName() and
pass the result to<br>
createTargetMachine() passed to the JIT. This patch
should be applied:<br>
<br>
<a moz-do-not-send="true"
href="http://llvm.org/bugs/show_bug.cgi?id=17422"
target="_blank">http://llvm.org/bugs/show_bug.cgi?id=17422</a><br>
<br>
Anyhow, the JIT was removed from current code and
will not be in next LLVM<br>
release.<br>
<br>
Yaron<br>
<br>
<br>
2014-09-17 22:27 GMT+03:00 Matt Godbolt <<a
moz-do-not-send="true"
href="mailto:matt@godbolt.org" target="_blank">matt@godbolt.org</a>>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Jim,<br>
<br>
Thanks for a very quick reply! That indeed does
the trick!<br>
<br>
Presumably the default has changed in 3.5 to be a
"generic" CPU<br>
instead of the native one? If that's the case I
wonder why: especially<br>
when JITting it really only makes sense to target
the actual CPU -<br>
unless I'm missing something? :)<br>
<br>
Thanks again,<br>
<br>
Matt<br>
<br>
On Wed, Sep 17, 2014 at 2:16 PM, Jim Grosbach <<a
moz-do-not-send="true"
href="mailto:grosbach@apple.com" target="_blank">grosbach@apple.com</a>>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0
0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
Hi Matt,<br>
<br>
I suspect you need to specify the target CPU
when you create the JIT.<br>
It’s just a method on the builder (e.g.,
builder.setMCPU(MCPU)). If you want<br>
auto-detection based on the host CPU,
sys::getHostCPUName() returns a value<br>
suitable to be passed directly into the builder.<br>
<br>
-Jim<br>
<br>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
On Sep 17, 2014, at 11:44 AM, Matt Godbolt
<<a moz-do-not-send="true"
href="mailto:matt@godbolt.org"
target="_blank">matt@godbolt.org</a>>
wrote:<br>
<br>
Hi guys,<br>
<br>
I just upgraded our JIT system to use llvm 3.5
and noticed one big<br>
change in our generated code: we don't see any
non-destructive VEX<br>
prefix instructions being emitted any more
(vmulsd xmm0, xmm1, blah)<br>
etc.<br>
<br>
It's long been on my list of things to
investigate anyway as I noticed<br>
llvm didn't emit VZEROUPPER calls either, so I
supposed it might not<br>
be a bad thing to disable vex.<br>
<br>
That being said, try as I might I can't force
avx on<br>
(builder.setMCPU("core-avx-i") and/or<br>
builder.setMAttrs(vector<string>{"+avx"});).
We're still using the old<br>
JIT but I just spiked out a move to MCJIT and
I still don't see the<br>
VEX instructions.<br>
<br>
Was there a deliberate change on the llvm-side
to discourage VEX<br>
instructions unless they make a big enough
difference (and/or is<br>
VZEROUPPER now emitted?).<br>
<br>
If not, how might I go about digging further
into this?<br>
<br>
Many thanks in advance, Matt<br>
<br>
--<br>
Matt<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a moz-do-not-send="true"
href="mailto:LLVMdev@cs.uiuc.edu"
target="_blank">LLVMdev@cs.uiuc.edu</a>
<a moz-do-not-send="true"
href="http://llvm.cs.uiuc.edu"
target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev"
target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote>
</blockquote>
<br>
<br>
--<br>
Matt<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a moz-do-not-send="true"
href="mailto:LLVMdev@cs.uiuc.edu"
target="_blank">LLVMdev@cs.uiuc.edu</a> <a
moz-do-not-send="true"
href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev"
target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a moz-do-not-send="true"
href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>
<a moz-do-not-send="true"
href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev"
target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>