GMP symbol naming (and the history thereof)?
rth at twiddle.net
Thu Feb 28 16:46:00 CET 2013
On 02/28/2013 12:50 AM, Torbjorn Granlund wrote:
> Richard Henderson <rth at twiddle.net> writes:
> Several times over the past week as I debug my neon routines, it has
> become painfully apparent (as I accidentally single-step into the
> dynamic linker) that the shared libgmp could use some help in
> modernizing its internal linkage.
> We are at least aware of these things ("Calls and linkage"):
Excellent. That's more or less exactly what I want to do.
> We're moving towards using fat libraries (--enable-fat) and there we are
> perhaps paying an even higher price for GOTs and PLTs.
> There are some specific GNU/Linux loader features which were
> discusssed here not long ago. I prefer to start portable, then do
> unportable tweaks. (Yes, the GNU system is the most important goal
> for the GNU project, but I want GMP to be great on every reasonable
I believe that IFUNC and the "fallback" fat system can live side-by side,
sharing most of the actual logic. The choice of which implementation to build
into the shared library can be made by configure.
> One reason for this is that we put some mpn functions in libc. They
> were there for many years, and last time I looked they where still
> there. We don't ever want to replace libc's internal routines for
> people that also link to GMP...
Fair enough. While you can't override the mpn routines in libc.so (they're
hidden), there is a potential issue with static linking. FWIW, glibc uses
"__mpn" as the prefix.
FWIW, on another library I wrote recently I used "pfx_" for the external names
and "PFX_" for the internal names.
More information about the gmp-devel