<div dir="ltr">Oh - I know what this is. You were running this on Linux, right?<div><br></div><div>On MacOS I think the symbol is getting double mangled while going through MCJIT::getSymbolAddress, hence the failure: The IR level foo function gets compiled to "_foo" in the object file, and then "_foo" gets mangled to "__foo" when we look it up. Linux doesn't do assembly level name-mangling, so this bug doesn't show up there.</div><div><br></div><div>Since applying this fixes Linux, and leaves MacOS no more broken than before, I'll put it in. Hopefully I can figure out a fix for MacOS soon.</div><div><br></div><div>Thanks again Charlie.</div><div><br></div><div>- Lang.</div><div> <br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 15, 2015 at 4:34 PM, Lang Hames <span dir="ltr"><<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Charlie,<div><br></div><div>Thanks for working on this. Sorry it took me so long to get around to looking at it.</div><div><br></div><div>I've just tested the patch out on Top-of-tree and I see:</div><div><br></div><font face="monospace, monospace"><span class="">ready> def foo(x y) x+y;<br>ready> Read function definition:<br>define double @foo(double %x, double %y) {<br>entry:<br>  %addtmp = fadd double %x, %y<br>  ret double %addtmp<br>}<br><br>ready> foo(1,2);<br>ready> Evaluated to 3.000000<br>ready> foo(3,4);<br></span>ready> LLVM ERROR: Program used extern function '_foo' which could not be resolved!</font><div><br></div><div>Have you seen the same thing? If not, can you describe your system config and I'll dig in and try to see what's causing this to behave differently for me.</div><div><br></div><div>- Lang.</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Fri, Dec 26, 2014 at 9:09 AM, Charlie Turner <span dir="ltr"><<a href="mailto:charlesturner7c5@gmail.com" target="_blank">charlesturner7c5@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">Hi all,<br>
<br>
Starting from Chapter 4 of the Kaleidoscope tutorial (where the JIT<br>
support is added), there's some strange behaviour,<br>
<br>
ready> def foo(x y) x+y;<br>
ready> Read function definition:<br>
define double @foo(double %x, double %y) {<br>
entry:<br>
  %addtmp = fadd double %x, %y<br>
  ret double %addtmp<br>
}<br>
<br>
ready> foo(1, 2);<br>
ready> Evaluated to 3.000000<br>
ready> foo(3, 4);<br>
ready> Evaluated to 3.000000<br>
<br>
You can see that foo(3, 4) is not being computed correctly. Well<br>
actually, it appears to not be getting compiled. It seems like the<br>
Kaleidoscope tutorial has slipped a bit with the recent JIT changes in<br>
LLVM.<br>
<br>
I have attached a patch which gets the above working. I found a blog<br>
post about getting Kaleidoscope working with MCJIT<br>
(<a href="http://blog.llvm.org/2013/07/using-mcjit-with-kaleidoscope-tutorial.html" target="_blank">http://blog.llvm.org/2013/07/using-mcjit-with-kaleidoscope-tutorial.html</a>)<br>
which most of the code comes from. Unfortunately that didn't<br>
completely work, it was using a deprecated API<br>
"RTDyldMemoryManager::getPointerToNamedFunction" which was failing to<br>
find function symbols for reasons I didn't have time to track down. I<br>
changed it to use the recommended getSymbolAddress, and now it works.<br>
<br>
If the attached seems reasonable, there's more to do,<br>
<br>
  * Updating the Kaleidoscope tutorial to explain all this. Andy<br>
Kaylor's blog post [1] is good place to start. There are other methods<br>
of using MCJIT in Kaleidoscope explained on that blog, but the<br>
attached method is perhaps the most straightforward one.<br>
  * Update all future chapter code to fix this bug.<br>
  * Updating the Kaleidoscope/MCJIT example code. This code doesn't<br>
get built when you request examples to be built, so it has suffered<br>
bit rot (doesn't compile at the moment, I have local patches for this<br>
but can submit those in the future). Should we be building this code<br>
more regularly?<br>
  * .... Bonus: Add unit tests to Kaleidoscope so it doesn't slip like<br>
this in the future?<br>
<br>
Am I on the right track with these fixes? If so I'll try and get to<br>
the points above, or at least raise a PR for it. Maybe in the meantime<br>
a note should be added to the tutorial that this is a known bug?<br>
<br>
Thanks for your time!<br>
<span><font color="#888888">Charlie.<br>
</font></span><br></div></div>_______________________________________________<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>
<br></blockquote></div><br></div>
</blockquote></div><br></div>