David Miller <da...@davemloft.net> writes: > My opinion is that IFUNC is valuable for the sake of turning what > would be two calls, into one through the PLT which is the minimum you > can get away with.
With the current GMP mechanism, you have the call through the PLT, followed by a jump through another function pointer. So sure, that's a small additional overhead, which it would be nice to get rid off. But not at any maintenance cost. You didn't answer anything regarding the needs of current GMP: Setting up multiple function pointers at more-or-less the same time, and also setting up machine-dependent data (with some requirements on the update ordering; iirc, first do all the data, then do all the pointers, but Torbjörn knows this a lot better than me). Maybe it's easy, but it's not the usual way IFUNC is setup? >From my admittedly limited understanding of ELF linking, I think it has to be done a bit differently if we update the pointers directly in the PLT. For one, iirc, each shared library has its own PLT for the functions it calls, right? So if you dynamically load another shared library using GMP, you get a new table of PLT pointers to be updated (and with IFUNC, they'll be updated on first call). Right? With the current method, there's only a single copy of each pointer, living in the data segment of libgmp.so. I hope you understand that switching to IFUNC exclusively is not an option: We want fat binaries also for non-glibc or non-elf systems. Then, if we use IFUNC, we need an easily maintainable way to support *both* IFUNC and something more portable. Trying to sort that out is the only way this discussion can be productive. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. _______________________________________________ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel