Speeding internal GMP calls

Kevin Ryde user42@zip.com.au
Wed, 18 Dec 2002 17:12:46 +1000


I wrote:
>
> On svr4 style x86, ld -Bsymbolic will send internal calls direct to
> their target, rather than via the PLT.  gcc and maybe some other
> compilers have -symbolic to pass that option.

Turns out this does bad things to global variables exported from a
shared library.

There ends up being two copies of a variable, one in the shared
library's data section, and one in the mainline program's (due to the
mainline being non-PIC).  Code in the library references the library
one, code in the mainline references the mainline one.  Not
surprisingly this bombs badly when code in one stores a value and the
code in the other tries to read it.

I guess this is the general rule of -Bsymbolic resolving symbols first
from the local module then elsewhere.  But it's a bit of a pest that
it bites when a mainline is merely doing "extern int foo".

Due to mpfr using __gmp_allocate_func etc, this makes -Bsymbolic a
non-starter for the time being.

We've also got __gmp_free_func in gmpxx.h for "string
mpz_class::get_str (int BASE = 10)" and likewise mpq, mpf and mpfr.
We never documented these in 4.1.1, so I think it's safe to change
them and stop internals like __gmp_free_func getting into application
binaries.

I'm thinking to make functions in libgmpxx like

	std::string get_str (mpz_srcptr z, int base);

Could even document these, to make them available to C++ programs not
otherwise wanting gmpxx.h.

Perhaps the name should be mpz_get_str?  Having "__mpz_struct" in the
parameters will make it as well-protected (or not) as the operators
already in libgmpxx.  But this is in gmp.h, so maybe the symbol
"get_str" should be protected against stray #defines, though such
things ought to be rare in C++ programs.