Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)
Subject: evaluate use of ELF symbol visibility pragmas for smaller
    code,GOT,PLT
X-RT-Original-Encoding: iso-8859-1
Content-Length: 1725

Newer versions of GCC on some platforms, including Linux and probably
other ELF platforms, have support for indicating the visibility of
symbols.  We're already using export lists (on the platforms where
we've figured out how to apply them) to limit the symbols exported
from a library.  However, making this information visible to the
compiler can improve code generation.  Rather than producing code to
use the shared library's procedure linkage table or global offset
table, the compiler can generate PC-relative calls within the library
when that's supported, perhaps also eliminating the usual PIC
load-GOT-address sequence from some functions.  Then the linker, in
turn, doesn't have to generate the PLT or GOT entries for symbols that
are going to be internal to the library anyways.

The downside is that it requires annotating some of our header files.

So, for example, we could mark profile_init with "protected"
visibility in the krb5 library; we'd get the faster function call
sequences within the krb5 library, and the symbol would still be
exported.  In the crypto code, most of the low-level implementation
functions -- at least, those that can be called directly instead of
through tables -- would be marked "hidden" or "internal".

The GCC implementation includes #pragma directives that can change the
default visibility for following symbol declarations, as well as
per-symbol attributes, so we're probably talking about adding some
lines at the beginning of headers (but after inclusion of system
headers), and some lines at the end to pop back to the previous state.
I don't think per-symbol annotations are needed for this.


Evaluate this more thoroughly at some point, figure out if it's worth doing.