<div dir="ltr">Hi Axel,<div><br></div><div>Sorry for the delay. Attached is the patch for RuntimeDyld & MCJIT (plus a proof-of-concept MCJIT setup that uses it). This was just a quick hack to work around this issue in MCJIT - it needs some polish, and it hasn't been tested with ORC yet. I think the full solution should look more like this:</div><div><br></div><div>1) In loadObject all symbols in the object should be added to the RuntimeDyld instance's symbol table, each marked weak or not as appropriate.</div><div>2) In RuntimeDyldImpl::loadObjectImpl weak symbols should be treated as if they were externals - i.e. we add symbolic relocations for each of them.</div><div>3) In RuntimeDyldImpl::resolveRelocations, for each weak symbol we first search the logical dylib for an existing strong definition. If we find one we use that, and remove the weak definition from the local table entirely. If we don't find an existing strong definition we mark our local definition as strong and use it.</div><div><br></div><div>Are you interested in implementing this?</div><div><br></div><div>Cheers,</div><div>Lang.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 29, 2016 at 9:47 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>Yep - RuntimeDyld does not handle weak symbols properly at the moment. About a month back I ran into a bug that I thought was due to this lack of weak symbol support (but that actually turned out to be something else) and wrote up a preliminary patch to fix it. When I get in to the office in a couple of hours I'll dig that patch up and see what kind of state it's in - it should serve as a good starting point.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>- Lang.</div></font></span></div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Fri, Apr 29, 2016 at 5:20 AM, Axel Naumann via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br></span><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
This is a question on how to resolve weak symbols from the binary for<br>
symbols that are also llvm::Module-local. Currently, the JIT seems to<br>
favor resolving to module-local symbols over existing symbols:<br>
<br>
$ cat symbols.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* interp);<br>
#ifdef BUILD_SHARED<br>
int compareAddr(int* interp) {<br>
if (interp != &StaticStuff<int>::s_data) {<br>
printf("Wrong address, %ld in shared lib, %ld in interpreter!\n",<br>
(long)&StaticStuff<int>::s_data,<br>
(long)interp);<br>
// CHECK-NOT: Wrong address<br>
return 1;<br>
}<br>
return 0;<br>
}<br>
#else<br>
# ifdef __CLING__<br>
int Symbols() {<br>
# else<br>
int main()<br>
# endif<br>
{ return compareAddr(&StaticStuff<int>::s_data);}<br>
#endif // ! BUILD_SHARED<br>
<br>
<br>
$ clang++ -shared -fPIC -DBUILD_SHARED symbols.cxx -o libSymbols.so<br>
$ clang++ -cc1 -emit-llvm symbols.cxx -o - | lli -load ./libSymbols.so -<br>
or<br>
$ clang++ -lSymbols symbols.cxx && ./a.out<br>
<br>
Compiled it's happy: the weak symbol used in main gets resolved to be<br>
the one in the binary for both references. That's the behavior I'd expect.<br>
<br>
The JIT OTOH is deciding that it shall use the local version of the<br>
symbol; RuntimeDyld::getSymbol() doesn't care about the fact that the<br>
symbol is weak and has an existing occurrence.<br>
<br>
For weak symbols from a different module, RuntimeDyld would use<br>
resolveExternalSymbols() and all would be good - but here this doesn't<br>
happen.<br>
<br>
IIUC, RuntimeDyld::getSymbol() really needs to check whether the local<br>
symbol should survive or not, before handing out its address. But that<br>
seems to break the whole design of when relocs happen, so I'm sure I'm<br>
wrong. Can I get some hints on how to implement the proper patch?<br>
<br>
Cheers, Axel.<br>
<br>
--<br>
ROOT - <a href="http://root.cern.ch" rel="noreferrer" target="_blank">http://root.cern.ch</a><br>
PH-SFT, CERN, 1211 Geneve 23, Switzerland<br>
Tel: <a href="tel:%2B41%2022%207678225" value="+41227678225" target="_blank">+41 22 7678225</a><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div></div><br></div>
</blockquote></div><br></div>