<div dir="auto">Just saw this (while looking for another patch).<div dir="auto"><a href="https://github.com/llvm/llvm-project/commit/ddf91af5a67bef9ca7a6f14277420e8d2dc0c66e">https://github.com/llvm/llvm-project/commit/ddf91af5a67bef9ca7a6f14277420e8d2dc0c66e</a><br></div><div dir="auto">Thanks! (Can we add a test so this part of kaleidoscope doesn't regress again?)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 20, 2019, 4:50 PM Lang Hames <<a href="mailto:lhames@gmail.com">lhames@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Ok. For the curious: The problem is that ORCv2 did away with symbol resolvers in favor of fixed symbol tables with resolution rules intended to match the static and dynamic linkers. That gave us a structure with which we could coordinate concurrent compilation, but took away our ability to arbitrarily hide old definitions (which is what we were relying on in the tutorial).</div><div><br></div><div>In the short term I think we can hack around this by detecting symbol clashes (DuplicateDefinition errors) in the KaleidoscopeJIT class and starting a new JITDylib each time we see one: Duplicate symbols within a dylib are not allowed, but duplicate symbols in *different* dylibs are. Then we just search our dylibs from last to first when resolving.</div><div><br></div><div>In the long term we would like a way to rename or delete symbol table entries (without deleting their underlying memory). This is probably still a little way off: deleting / renaming in the context of concurrent compilation is tricky.</div><div><br></div><div>Cheers,</div><div>Lang.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 20, 2019 at 3:20 PM Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank" rel="noreferrer">lhames@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">Not yet unfortunately. I've had my head down working on a jut-linker replacement.<div><br></div><div>Let me take a look right now...</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 18, 2019 at 10:40 AM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank" rel="noreferrer">dblaikie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Ping - did this end up getting addressed?<br><br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 21, 2019, 6:15 PM Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank" rel="noreferrer">lhames@gmail.com</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto">Hi Nick,<div><br></div><div>I was not aware of it, but it makes sense given the recent switch to ORC2, which has different symbol resolution rules.</div><div><br></div><div>I am out on vacation this week, but will take a look when I get back and see if I can restore the old behavior.</div><div><br></div><div>Cheers,</div><div>Lang.<br><br><div id="m_1592442133868244849gmail-m_-7200144179892242711gmail-m_-8290908072853519814m_-4660625428008523853AppleMailSignature" dir="ltr">Sent from my iPhone</div></div></div><div dir="auto"><div><div dir="ltr"><br>On Jan 20, 2019, at 2:14 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank" rel="noreferrer">dblaikie@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><div dir="ltr">+Lang who does JIT things<br><br>Yeah, I can confirm my local build (using LLVM source from today) of Chapter 4 behaves as you describe, and not as the documentation shows. Looks like somethnig needs updating (either source or the documentation).<br><br><div class="gmail_quote"><div dir="ltr" class="m_1592442133868244849gmail-m_-7200144179892242711gmail-m_-8290908072853519814m_-4660625428008523853gmail_attr">On Sun, Dec 30, 2018 at 3:28 PM Nick Desaulniers via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><a href="https://llvm.org/docs/tutorial/LangImpl04.html" rel="noreferrer noreferrer" target="_blank">https://llvm.org/docs/tutorial/LangImpl04.html</a> has an example where<br>
the function `foo` gets redefined, and the JIT returns evaluation of<br>
the latest definition.  I thought my code was wrong, but it seems that<br>
the binary produced by `ninja Kaleidoscope-Ch4` has the same bug.<br>
<br>
Granted, my LLVM checkout is from Nov 3 2018 (r346062).  Is this a known issue?<br>
~Nick Desaulniers<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>
</div></blockquote></div></div></blockquote></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>