GMP symbol naming (and the history thereof)?
Richard Henderson
rth at twiddle.net
Thu Feb 28 00:23:48 CET 2013
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.
Most important is arranging for calls within GMP to go through private
names, so that e.g. mpn_mul doesn't have to go through the PLT in order
to reach mpn_addmul_1.
There are several ways to approach this fix, and I can talk about those
in followups, but to begin we need to have a discussion as to exactly
what the public interface is. This dove tails nicely with the work that
Neils has done recently with tidying up mpn.
What I'm curious about is the "__g" prefix associated with 95% of the
symbols. Why is gmp defining symbols in the namespace reserved to the
compiler and "the implementation" aka the standard c library? I mean, I
guess we're not actually getting into trouble for it, since it's
actually working, but I don't think it's very "clean".
If at some point we make some change that requires the bumping of the
shared library version number, I think it would be a good opportunity to
drop the prefix, bringing the API and ABI names back in sync. But until
we do make some other incompatible ABI change it's probably not worth it.
But the first thing to do is to confirm exactly what API symbols should
be exported. I'm going to begin with the assumption that if it isn't
declared in gmp-h.in, then it's not public.
r~
More information about the gmp-devel
mailing list