Rethinking GMP's configure

[Torbjorn Granlund]

nisse at lysator.liu.se (Niels Möller) writes:

  This may get in the way, but that should not be a real problem. An
  exported function like mpn_add_n should point to a wrapper which jumps
  via a table. User code should never see any pointer to the internal
  functions which are pointed to in that table.
  
Yes, this is how it *should* work.  :-)

  So __gmpn_add_n is ELF "default", while __gmpn_bobcat_add_n (or whatever
  the symbol name is) can be ELF "hidden".

Yes.  For an ELF solib, that would help (and this is something which is
largely independent of the rest, and an optimisation which we have
planned for some time).

(I think some other object formats have support for speeding up internal
solib calls.  Darwin has .private_extern, which might work as either
protected or hidden.)

  Then it's even better if internal calls to mpn_add_n are macros which
  jump directly via the table, and not to the mpn_add_n wrapper function.

I'm not sure I follow this.

There is a pointer table __gmpn_cpuvec which is used for all internal
calls.  Initially, it points to functions like __gmpn_add_n_init, which
save the state and calls out to the a C function (in x86*/fat/fat.c)
that fills out the __gmpn_cpuvec table with the right routines for the
host.

External calls go through tiny trampoline functions in fat_entry.asm.
(This seems hard to fix, without GNU ELF's IFUNC.)

  One could also use ELF "protected" for the wrapper function, but I think
  I read that Ian didn't recommended not using "protected", iirc, because
  of pointer comparison complications which aren't handled efficiently by
  the current ld.so.
  
We should use hidden for internal symbls and hissen+alias for documented
symbols.  (I suppose we shouldn't be fascist and forcibly hiding
internal symbls.  I know some project use them knowing that they are
outside of the "offical" GMP interface.  Hiding symbols that people use
seem silly.  If we need to change the interface so that their code
breaks, that's a different story.  So let's use alias even for some
internals.  Hey, we could even define "documented internal" functions,
with proper warnings attached.)

-- 
Torbjörn