GMP symbol naming (and the history thereof)?

[Torbjorn Granlund]

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"):
https://gmplib.org/devel/GMPng.html

  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.
  
Agreed.

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
platform.)

  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
interface.

  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"
existed.  :-)

  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.
  
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.  :-)

-- 
Torbjörn