[llvm-dev] LLVM gold plugin do not add llvm instrinsics symbols to the linker symbol table

Fri Mar 23 10:00:21 PDT 2018

+pcc for thoughts

On Fri, Mar 23, 2018 at 9:37 AM, Bakhvalov, Denis <denis.bakhvalov at intel.com
> wrote:

> Hello Teresa,
>
>
>
> > Without -flto, a.o ends up with a reference to __exp_finite,
>
> That’s correct.
>
>
>
> > which also would not be satifisfied out of libexp.a.
>
> That’s not correct. Even if libexp.a would have __exp_finite, it wouldn’t
> be resolved from libexp.a, because of the behavior described in my first
> message.
>

I'm asking specifically about the non-LTO case.

>
>
> > Do you also have an implementation of __exp_finite in your libexp.a?
>
> No, I don’t have __exp_finite in libexp.a. I presented complete code in my
> first message. You can reproduce it yourself on current trunk.
>

I did. I'm trying to understand how the non-LTO case is supposed to work. I
assume in your full code you must have an implementation of __exp_finite in
your libexp.a so that it is satisfied out of there and not libm.so (in the
non-LTO case). I.e. when I try the example from your message, but remove
-flto, I get the __exp_finite that is satisfied out of libm.so. I'm just
trying to verify my assumption that you are providing that as well in your
full library.

>
>
> > Can you build with -fno-builtin, or -fno-builtin-exp etc?
>
> > That results in a reference to __exp_finite in the .o bitcode
>
> > (which of course has the same issue I mentioned above, but is
> consistent).
>
> > That seems to be the option you should use here when you want to use
> your own implementations.
>
>
>
> Yes, -fno-builtin results in call to __exp_finite in the bitcode. But the
> problem I try to address is not what version of exp libcall we want to
> generate: exp or __exp_finite.
>
> The problem is that if the exp call was lowered to llvm intrinsic, linker
> doesn’t resolve it from my static library in LTO build, because plugin
> (LLVMgold.so) doesn’t report those symbols (yet in intrinsic form) to the
> linker.
>

Right, which is why I am suggesting that it might be appropriate to build
with -fno-builtin (or -fno-builtin-exp) here - this solves the LTO issue as
there will no longer be an llvm intrinsic in the bitcode. Although it is
not friendly that there is different behavior between the LTO and non-LTO
cases here.

Note that this is not specific to the gold plugin case either. With
-fuse-ld=lld:

./libexp.a: lazy definition of exp
/lib/x86_64-linux-gnu/libm.so.6: shared definition of exp
$ nm a.out | grep exp
                 U exp

Teresa

>
>
> Best regards,
> Denis Bakhvalov.
>
> ---------------------------------------------------------------------
>
> *Intel Technology Poland sp. z o.o.*ul. S
> <https://maps.google.com/?q=ul.+S+owackiego+173+%7C+80-298+Gda+sk&entry=gmail&source=g>
> &#322owackiego 173 | 80-298 Gda
> <https://maps.google.com/?q=ul.+S+owackiego+173+%7C+80-298+Gda+sk&entry=gmail&source=g>
> &#324sk
> <https://maps.google.com/?q=ul.+S+owackiego+173+%7C+80-298+Gda+sk&entry=gmail&source=g>
> | S&#261d Rejonowy Gda&#324sk P&#243&#322noc | VII Wydzia&#322 Gospodarczy
> Krajowego Rejestru S&#261dowego - KRS 101882 | NIP 957-07-52-316 |
> Kapita&#322 zak&#322adowy 200.000 PLN.
>
> Ta wiadomo&#347&#263 wraz z za&#322&#261cznikami jest przeznaczona dla
> okre&#347lonego adresata i mo&#380e zawiera&#263 informacje poufne. W razie
> przypadkowego otrzymania tej wiadomo&#347ci, prosimy o powiadomienie
> nadawcy oraz trwa&#322e jej usuni&#281cie; jakiekolwiek przegl&#261danie
> lub rozpowszechnianie jest zabronione.
> This e-mail and any attachments may contain confidential material for the
> sole use of the intended recipient(s). If you are not the intended
> recipient, please contact the sender and delete all copies; any review or
> distribution by others is strictly prohibited.
>
>

-- 
Teresa Johnson |  Software Engineer |  tejohnson at google.com |  408-460-2413
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180323/c252b101/attachment.html>