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