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.