[llvm-dev] LLJIT: __{math}_finite symbols not resolved ?

[Lang Hames via llvm-dev]

Hi Jean-Michaël,

Thanks very much for the reproduction case. I'll try this out tomorrow.

If you can't take the address of __<F>_finite, then what about defining
your own <F>_wrapper functions and using their addresses when defining the
absolute symbols? I'm not sure what the performance implications would be
for your use-case though.

-- Lang.

On Mon, Oct 5, 2020 at 3:23 PM Jean-Michaël Celerier <
jeanmichael.celerier at gmail.com> wrote:

> Hello,
> here is a repro which runs in a docker image.
> https://we.tl/t-O1EhIAOeOF
>
> To see the issue, run repro.sh
> It will first download a (big, sorry) centos:7 docker image with my build
> of LLVM-11 and build a simple lljit-based example.
>
> This example is called with some trivial .cpp which calls `cos`.
> When ran from *within the container* it works.
> When the same example, with the same bitcode input, runs from outside the
> container, it does not find this symbol,
> likely because the host (in my case Arch, I think you need a glibc-2.31 at
> least for that behaviour to be visible)'s glibc symbols
> became versioned.
> Removing either the -fmath-errno or -ffinite-math-only flag for the clang
> cpp -> bitcode invocation in build.sh fixes the issue
> (at the expense of potentially slower code).
>
> <http://www.jcelerier.name>
> Thanks for the hint, sadly it's not possible to take the address of
> __log_finite : what happens is that you call the function e.g. log()
> in your code, and either clang or some magic glibc header transforms that
> into __log_finite further down the pipeline
> (see e.g. the discussion in https://reviews.llvm.org/D74712 - sadly in my
> case I can't "upgrade" the headers used by my JIT SDK to glibc-2.31+
> as it would mean that only people with very very recent distros would be
> able to run the code that's being jit-compiled.
>
> Thanks !
>
> Jean-Michaël
>
> On Mon, Oct 5, 2020 at 10:11 PM Lang Hames <lhames at gmail.com> wrote:
>
>> Hi Jean-Michaël,
>>
>> Ok -- if you're linking against other symbols without issue then your
>> setup sounds good.
>>
>> 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.
>>
>> In the meantime one workaround would be to define absoluteSymbol entries
>> for these functions:
>>
>> auto Err = J->getMainJITDylib().define(
>>   absoluteSymbols({
>>     { J->mangleAndIntern("__log_finite"),
>> pointerToJITTargetAddress(&__log_finite) },
>>     { J->mangleAndIntern("__exp2_finite"),
>> pointerToJITTargetAddress(&__exp2_finite) }
>>  }));
>>
>> -- Lang.
>>
>> On Mon, Oct 5, 2020 at 12:31 PM Jean-Michaël Celerier <
>> jeanmichael.celerier at gmail.com> wrote:
>>
>>> Hello,
>>> Right now I am just using a Generator to look for symbols in my process
>>> (which links dynamically against libc / libm).
>>> 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:
>>>
>>>   $ nm -D /usr/lib/libm.so.6 |  grep finite
>>>   0000000000050540 T __acosf128_finite at GLIBC_2.26
>>>   0000000000042f70 T __acosf_finite at GLIBC_2.15
>>>   0000000000026940 i __acos_finite at GLIBC_2.15
>>>   0000000000051000 T __acoshf128_finite at GLIBC_2.26
>>>   0000000000043240 T __acoshf_finite at GLIBC_2.15
>>> )
>>> but maybe it needs some help on that regard ?
>>>
>>> Thanks for your quick answer,
>>>
>>> Jean-Michaël
>>>
>>>
>>> On Mon, Oct 5, 2020 at 7:53 PM Lang Hames <lhames at gmail.com> wrote:
>>>
>>>> Hi Jean-Michaël,
>>>>
>>>> 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?
>>>>
>>>> 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.
>>>>
>>>> -- Lang.
>>>>
>>>> On Mon, Oct 5, 2020 at 12:52 AM Jean-Michaël Celerier via llvm-dev <
>>>> llvm-dev at lists.llvm.org> wrote:
>>>>
>>>>> Hello,
>>>>> when building code with -Ofast -ffinite-math-only -ffast-math, clang
>>>>> generates calls to "finite" variants of math functions.
>>>>>
>>>>> 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.
>>>>> - https://bugs.llvm.org/show_bug.cgi?id=44842
>>>>> - https://github.com/cms-sw/cmssw/issues/24935
>>>>> - https://github.com/google/filament/issues/2146
>>>>>
>>>>> But when going through LLJIT (tested with LLVM-10 & LLVM-11, on
>>>>> ArchLinux, glibc-2.32) I still get
>>>>>
>>>>>      Symbols not found: [ __log_finite, __exp2_finite ]
>>>>>
>>>>> when trying to materialize my code.
>>>>>
>>>>> 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.
>>>>>
>>>>> Thanks,
>>>>> Jean-Michaël
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> llvm-dev at lists.llvm.org
>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201005/95db30b0/attachment.html>