<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Jean-Michaël,<div><br></div><div>Ok -- if you're linking against other symbols without issue then your setup sounds good.</div><div><br></div><div>My first take is that if you're set up correctly then this should "just work", and this failure should be considered a bug, but I need to understand more about ELF indirect / versioned symbols before I can say that definitively. I usually develop on MacOS, but I'll set up a VM and see if I can reproduce this locally to get some more insight here.</div><div><br></div><div>In the meantime one workaround would be to define absoluteSymbol entries for these functions:</div><div><br></div><div><font face="monospace">auto Err = J->getMainJITDylib().define(</font></div><div><font face="monospace">  absoluteSymbols({</font></div><div><div style="color:rgb(0,0,0)"><font face="monospace">    { J->mangleAndIntern("__log_finite"), pointerToJITTargetAddress(&__log_finite) },</font></div><div style="color:rgb(0,0,0)"><font face="monospace">    { J->mangleAndIntern("__exp2_finite"), pointerToJITTargetAddress(&__exp2_finite) }</font></div></div><div style="color:rgb(0,0,0)"><font face="monospace"> }));</font></div><div><br></div><div>-- Lang.</div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 5, 2020 at 12:31 PM Jean-Michaël Celerier <<a href="mailto:jeanmichael.celerier@gmail.com">jeanmichael.celerier@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"><div>Hello, <br></div><div>Right now I am just using a Generator to look for symbols in my process (which links dynamically against libc / libm). <br></div><div>It seems to have no trouble finding every other libc / libm / libc++ / ... symbol so I assumed that it was not necessary to specifically link against libm where these __finite symbols reside: <br></div><div><br></div><div>  $ nm -D /usr/lib/libm.so.6 |  grep finite <br>  0000000000050540 T __acosf128_finite@GLIBC_2.26<br>  0000000000042f70 T __acosf_finite@GLIBC_2.15<br>  0000000000026940 i __acos_finite@GLIBC_2.15<br>  0000000000051000 T __acoshf128_finite@GLIBC_2.26<br>  0000000000043240 T __acoshf_finite@GLIBC_2.15<br></div><div><div><div dir="ltr"><div dir="ltr"><div>)</div><div>but maybe it needs some help on that regard ? <br></div><div><br></div><div>Thanks for your quick answer,</div><div><br></div><div>Jean-Michaël<br></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 5, 2020 at 7:53 PM Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank">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"><div dir="ltr">Hi Jean-Michaël,<div><br></div><div>How are you trying to provide those symbols to the JIT? Are you using a DynamicLibrarySearchGenerator to reflect process symbols (or this specific library's symbols) into the JIT?</div><div><br></div><div>I haven't looked at ELF symbol indirection before -- I'll need to read up on that before I can provide a sensible answer. It's quite likely that RuntimeDyld doesn't support it yet though. Depending on what is required we can either try to implement it there, or aim to fix it in the newer JITLink linker -- a few people are working on an initial implementation of that at the moment.</div><div><br></div><div>-- Lang.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 5, 2020 at 12:52 AM Jean-Michaël Celerier via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">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"><div dir="ltr"><div>Hello,</div><div>when building code with -Ofast -ffinite-math-only -ffast-math, clang generates calls to "finite" variants of math functions.</div><div><br></div><div>This has been the source of a fair amount of issues in a "normal", non-JIT pipeline, which seem to have been fixed over time - a simple fix being recompiling the target app against the new glibc. <br><div>- <a href="https://bugs.llvm.org/show_bug.cgi?id=44842" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=44842</a> <br></div><div>- <a href="https://github.com/cms-sw/cmssw/issues/24935" target="_blank">https://github.com/cms-sw/cmssw/issues/24935</a></div></div><div>- <a href="https://github.com/google/filament/issues/2146" target="_blank">https://github.com/google/filament/issues/2146</a></div><div><br></div><div>But when going through LLJIT (tested with LLVM-10 & LLVM-11, on ArchLinux, glibc-2.32) I still get <br></div><div><br></div><div>     Symbols not found: [ __log_finite, __exp2_finite ]</div><div><br></div><div>when trying to materialize my code.</div><div><br></div><div>What could be done for that ? "Recompiling" doesn't seem to fix anything in this case so it looks like LLJIT lacks the mechanism to understand the ELF symbol indirection.<br></div><div><br></div><div>Thanks,</div><div>Jean-Michaël<br> </div></div>
_______________________________________________<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="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>