<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><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><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 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 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 href="http://llvm.org/bugs/show_bug.cgi?id=17422" target="_blank">http://llvm.org/bugs/show_bug.<u></u>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 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 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 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<<u></u>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>
______________________________<u></u>_________________<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/<u></u>mailman/listinfo/llvmdev</a><br>
</blockquote></blockquote>
<br>
<br>
--<br>
Matt<br>
<br>
______________________________<u></u>_________________<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/<u></u>mailman/listinfo/llvmdev</a><br>
</blockquote>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
______________________________<u></u>_________________<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/<u></u>mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div>