GMP symbol naming (and the history thereof)?
tg at gmplib.org
Thu Feb 28 09:50:29 CET 2013
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"):
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.
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
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.
We indeed don't want to make hidden every undocumented function. The
plan is to use hidden for every symbol, and add aliases for all
undocumented plus any function people use outside of the documented
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".
We're staying in a quite limited namespace, not __g but __gmp.
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...
Another reason is to stay away from the user name space with our
internal routines. Today we can do that more cleanly, at least on ELF
systems, but GMP was born in 1991 before these "teenage features"
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
Hmm. I suppose we could add that to
https://gmplib.org/devel/incompatibility.html. (I am thinking GMP 6.0
for an incompatible GMP. We're probably doing GMP 5.2 first. I am
trying to step down from my GMP "dictator" role and instead be a
member of a "junta", so I'm not going to make this decisions alone.)
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.
We could start there, and wait for the screams. :-)
More information about the gmp-devel