<div dir="ltr">Hi Philip,<div><br></div><div>Ahh. Sorry to hear. The good news is that I have a plan to make it better. The bad news is that I don't have a timeline. I'm trying to squash a few critical bugs in the infrastructure at the moment and then I'll start putting out proposals and asking for volunteers. :)</div><div><br></div><div>- Lang.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 18, 2014 at 11:01 AM, 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">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span class="">
    <br>
    <div>On 09/18/2014 10:17 AM, Lang Hames
      wrote:<br>
    </div>
    <blockquote 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></span>
    I know.  This is what I'm actually doing today.  :)<span class=""><br>
    <blockquote 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></span>
    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)<div><div class="h5"><br>
    <blockquote 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 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><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><font color="#888888"><br>
                <br>
                Philip</font></span>
            <div>
              <div><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.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<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 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/mailman/listinfo/llvmdev</a><br>
                        </blockquote>
                      </blockquote>
                      <br>
                      <br>
                      --<br>
                      Matt<br>
                      <br>
                      _______________________________________________<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/mailman/listinfo/llvmdev</a><br>
                    </blockquote>
                    <br>
                  </blockquote>
                  <br>
                  <br>
                </blockquote>
                <br>
                _______________________________________________<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/mailman/listinfo/llvmdev</a><br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </div></div></div>

</blockquote></div><br></div>