GMP work on symbol visibility

[Niels Möller]

tg at gmplib.org (Torbjörn Granlund) writes:

> We should never forget that the most important aspect of our tests is to
> catch miscompilatilons.

If we build static and shared libraries from the same object files (I
suspect automake and libtool doesn't do that for us now), testing the
static library should detect miscompilations. But not mislinking,
including broken link-time optimizations.

And even if we don't do that, I would hope that the risk that a
miscompiled object file is caught by unit tests of internal functions,
but not by the tests of public gmp functions, is pretty low.

To make an informed decision, I think it would help to compile a rough
list of the functions to hide.

> http://www.airs.com/blog/archives/307

Is this 6 year old post still valid? The runtime linker could build some
index to avoid extra walks over symbol tables. I guess it would also be
useful with some function __attribute__ expressing that "I don't give a
damn if pointer comparison for address(es) to this function work
according to the C standard".

> I wonder if one could edit the .so file and make hidden symbols visible
> again.  Perhaps objcopy knows how to do that?

The point of hidden is to completely remove the symbols from the symbol
table in the shared object, right? So to get them back, I guess one
would need to reconstruct GOT and PLT entries either from the object
files or from debug info. Perhaps one can relink the .so file with some
linker flag saying "ignore hidden"? Or simply collect the object files
into a static library.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.