Skip Menu |
 

Subject: evaluate use of ELF symbol visibility pragmas for smaller code,GOT,PLT
Download (untitled) / with headers
text/plain 1.6KiB
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.
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #3316] evaluate use of ELF symbol visibility pragmas for smaller code, GOT, PLT
From: Sam Hartman <hartmans@mit.edu>
Date: Wed, 28 Dec 2005 18:16:41 -0500
RT-Send-Cc:
My personal opinion is that if we can do this in a manner where we
guarantee that the symbol visibility and export lists do not conflict
then we should do so.

We should also make sure that in cases where features we need are not
available we do not use them.

--Sam
From: Ken Raeburn <raeburn@MIT.EDU>
Subject: Re: [krbdev.mit.edu #3316] evaluate use of ELF symbol visibility pragmas for smaller code, GOT, PLT
Date: Wed, 28 Dec 2005 18:35:52 -0500
To: rt-comment@krbdev.mit.edu
RT-Send-Cc:
On Dec 28, 2005, at 18:16, Sam Hartman via RT wrote:
Show quoted text
> My personal opinion is that if we can do this in a manner where we
> guarantee that the symbol visibility and export lists do not conflict
> then we should do so.

There are two main types of conflict there.

First, a symbol marked hidden/internal but in the export list. From
a test I did a little while ago, it appears that it wouldn't show up
in the dynamic symbol table. I was thinking of adding a test program
that would walk through the export list and try calling dlsym on each
symbol.

Second, a symbol with default visibility but not in the export list.
This would be okay, it's just likely to be less efficient. Though
for platforms where visibility is supported but export lists are not
(are there any?), it might be desirable to run nm and examine the
output for unrecognized, defined symbols.

Show quoted text
> We should also make sure that in cases where features we need are not
> available we do not use them.

Yup.

Ken
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #3316] evaluate use of ELF symbol visibility pragmas for smaller code, GOT, PLT
From: Sam Hartman <hartmans@mit.edu>
Date: Thu, 29 Dec 2005 21:31:31 -0500
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.2KiB
Show quoted text
>>>>> "Ken" == Ken Raeburn via RT <rt-comment@krbdev.mit.edu> writes:

Show quoted text
Ken> On Dec 28, 2005, at 18:16, Sam Hartman via RT wrote:
Show quoted text
>> My personal opinion is that if we can do this in a manner where
>> we guarantee that the symbol visibility and export lists do not
>> conflict then we should do so.

Show quoted text
Ken> There are two main types of conflict there.

Show quoted text
Ken> First, a symbol marked hidden/internal but in the export
Ken> list. From a test I did a little while ago, it appears that
Ken> it wouldn't show up in the dynamic symbol table. I was
Ken> thinking of adding a test program that would walk through the
Ken> export list and try calling dlsym on each symbol.

Show quoted text
Ken> Second, a symbol with default visibility but not in the
Ken> export list. This would be okay, it's just likely to be less
Ken> efficient. Though for platforms where visibility is
Ken> supported but export lists are not (are there any?), it might
Ken> be desirable to run nm and examine the output for
Ken> unrecognized, defined symbols.

O, sorry, I meant to imply that we should set things up so all our
symbol properties come from one place. I.E. it is impossible to get
it wrong because there is only one place the data lives so it cannot
be inconsistent with anything.

--Sam
From: Ken Raeburn <raeburn@MIT.EDU>
Subject: Re: [krbdev.mit.edu #3316] evaluate use of ELF symbol visibility pragmas for smaller code, GOT, PLT
Date: Thu, 29 Dec 2005 22:51:20 -0500
To: rt-comment@krbdev.mit.edu
RT-Send-Cc:
On Dec 29, 2005, at 21:31, Sam Hartman via RT wrote:
Show quoted text
> O, sorry, I meant to imply that we should set things up so all our
> symbol properties come from one place. I.E. it is impossible to get
> it wrong because there is only one place the data lives so it cannot
> be inconsistent with anything.

Ah, I see. That might be tricky, since one is markers in a header
file related only by position to the function declarations, and the
other is a list of symbols, but perhaps something can be worked up,
maybe parsing the header file to generate the initial symbol list.