<div dir="ltr">Hi Axel,<div><br></div><div>Sorry for the delay.<br><br></div><div>r231896 goes some way towards addressing this issue, but we need to thread the new class (RuntimeDyld::SymbolInfo) through MCJIT and RTDyldMemoryManager before we can really do what Keno wants. I'll put a mail out on the list warning clients about the change - hopefully we can get the ball rolling on this quickly.</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, Feb 18, 2015 at 11:10 AM, 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 Axel,<div><br></div><div>Sorry about the delay in checking this out. I'm working through my review backlog - Keno's weak symbol patch is next on the list, then this.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>- Lang.</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 6, 2015 at 3:36 AM, Axel Naumann <span dir="ltr"><<a href="mailto:Axel.Naumann@cern.ch" target="_blank">Axel.Naumann@cern.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Keno and Lang,<br>
<br>
I'm currently test driving cling with the OrcJIT - your r227228 is<br>
obviously crucial there, too.<br>
<br>
I needed the attached patch on top, else I had symbols emitted (bumping<br>
up UnfinalizedSections) without a corresponding NotifyFinalizedT call<br>
because the symbol could not be found by<br>
LazyEmittingLayer::EmissionDeferredSet::Search()'s call to<br>
B.lookupSymbolAddressIn() and thus the ObjectHandle was never finalized.<br>
<br>
I think it would be good to assert that an Emit()ed ObjectHandle is also<br>
finalized - this seems to be a fairly fundamental assumption e.g. for<br>
the Orc MCJIT replacement.<br>
<br>
I'm not sure how to create a simple test for this, though. Please let me<br>
know whether my description allows you to do that or whether I need to<br>
spend more time in reducing our test cases...<br>
<br>
Cheers, Axel<br>
<br>
<br>
On 13.01.2015 17:07, Keno Fischer wrote:<br>
> Hi Axel.<br>
><br>
> I put up a patch at <a href="http://reviews.llvm.org/D6950" target="_blank">http://reviews.llvm.org/D6950</a>. Have a look and see<br>
> if it works for you.<br>
><br>
> Thanks,<br>
> Keno<br>
><br>
> On Tue, Jan 13, 2015 at 9:44 AM, Axel Naumann <<a href="mailto:Axel.Naumann@cern.ch" target="_blank">Axel.Naumann@cern.ch</a><br>
> <mailto:<a href="mailto:Axel.Naumann@cern.ch" target="_blank">Axel.Naumann@cern.ch</a>>> wrote:<br>
><br>
> Hi Keno,<br>
><br>
> The part that scares me a bit is<br>
><br>
> > and then adjust the other methods to not<br>
> > bail out two quickly when encountering a weak symbol.<br>
><br>
> I would very much appreciate if you could implement this; I don't have<br>
> enough knowledge of the MCJIT nor llvm CodeGen internals... I will<br>
> happily try it out and provide you with feedback, though! :-)<br>
><br>
> Thank you *so* much for your fast reaction!<br>
><br>
> Cheers, Axel<br>
><br>
><br>
><br>
> On 13.01.2015 00:30, Keno Fischer wrote:<br>
> > Hi Axel,<br>
> ><br>
> > the problem is that weak symbols are not handled in RuntimeDyld at all.<br>
> > The proper solution is probably to add a separate case for weak symbols<br>
> > (where we're already taking care of common symbols) in<br>
> > RuntimeDyld::loadObjectImpl and then adjust the other methods to not<br>
> > bail out two quickly when encountering a weak symbol.<br>
> ><br>
> > Please let me know if you're planning to work on a patch for this,<br>
> > otherwise I'll have a go tomorrow.<br>
> ><br>
> > Thanks,<br>
> > Keno<br>
> ><br>
> > On Mon, Jan 12, 2015 at 11:45 AM, Axel Naumann <<a href="mailto:Axel.Naumann@cern.ch" target="_blank">Axel.Naumann@cern.ch</a> <mailto:<a href="mailto:Axel.Naumann@cern.ch" target="_blank">Axel.Naumann@cern.ch</a>><br>
> > <mailto:<a href="mailto:Axel.Naumann@cern.ch" target="_blank">Axel.Naumann@cern.ch</a> <mailto:<a href="mailto:Axel.Naumann@cern.ch" target="_blank">Axel.Naumann@cern.ch</a>>>> wrote:<br>
> ><br>
> > Hi,<br>
> ><br>
> > I'm finally moving cling to MCJIT - and MCJIT is wonderful! So<br>
> far I<br>
> > only ran into this issue:<br>
> ><br>
> > $ cat linkonceodr.cxx<br>
> > extern "C" int printf(const char*,...);<br>
> ><br>
> > template <class T> struct StaticStuff {<br>
> > static T s_data;<br>
> > };<br>
> > template <class T> T StaticStuff<T>::s_data = 42;<br>
> ><br>
> > int compareAddr(int* mcjit);<br>
> ><br>
> > #ifdef BUILD_SHARED<br>
> > int compareAddr(int* mcjit) {<br>
> > if (mcjit != &StaticStuff<int>::s_data) {<br>
> > printf("Wrong address, %ld in shared lib, %ld in mcjit!\n",<br>
> > (long)&StaticStuff<int>::s_data, (long)mcjit);<br>
> > return 1;<br>
> > }<br>
> > return 0;<br>
> > }<br>
> > #else<br>
> > int main(int, char**) {<br>
> > return compareAddr(&StaticStuff<int>::s_data);<br>
> > }<br>
> > #endif<br>
> ><br>
> ><br>
> > $ clang++ -fPIC -shared -DBUILD_SHARED -o liblinkonceodr.so<br>
> > linkonceodr.cxx<br>
> > $ clang++ -emit-llvm -c linkonceodr.cxx -o - |<br>
> > LD_PRELOAD=./liblinkonceodr.so lli -<br>
> > Wrong address, 140449908087496 in shared lib, 140449908076544<br>
> in mcjit!<br>
> ><br>
> ><br>
> > I.e. while compareAddr is resolved from the dylib, this:<br>
> ><br>
> > @_ZN11StaticStuffIiE6s_dataE = linkonce_odr global i32 42, align 4<br>
> ><br>
> > is not: it is re-emitted by the MCJIT. When building a binary and<br>
> > linking against that dylib, _ZN11StaticStuffIiE6s is correctly<br>
> picked up<br>
> > from the dylib. I would expect MCJIT to behave the same.<br>
> ><br>
> > I'll try to fix that myself, but I'd appreciate a hint where<br>
> to do that.<br>
> > Should I collect linkonce_odr-s and "replace" their emitted<br>
> code as part<br>
> > of llvm::RuntimeDyldImpl::resolveRelocations()? Or is this just a<br>
> > missing case somewhere?<br>
> ><br>
> > That's e.g. with<br>
> ><br>
> > $ lli --version<br>
> > LLVM (<a href="http://llvm.org/" target="_blank">http://llvm.org/</a>):<br>
> > LLVM version 3.6.0svn<br>
> > Optimized build.<br>
> > Built Jan 12 2015 (10:52:59).<br>
> > Default target: x86_64-unknown-linux-gnu<br>
> > Host CPU: corei7-avx<br>
> ><br>
> ><br>
> > Cheers, Axel.<br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > LLVM Developers mailing list<br>
> > <a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <mailto:<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>><br>
> <mailto:<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <mailto:<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>>><br>
> > <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>
> ><br>
><br>
><br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>