arm "neon"

[Niels Möller]

David Miller <davem at 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.