We'd like to extend the meaning of the ELF symbol ST_VISIBILITY
bits. These aliases are all I can dig up from past collaborations.
Our main goal is not to clash with any ELF extensions that may
already exist, or are in the works by other vendors.
Comments welcome. Perhaps just responding to:
generic-abi at googlegroups.com ?
We'd like to add:
#define STV_DEFAULT 0
#define STV_INTERNAL 1
#define STV_HIDDEN 2
#define STV_PROTECTED 3
#define STV_SINGLETON 4 <--- New
#define STV_ELIMINATE 5 <--- New
#define ELF32_ST_VISIBILITY(o) ((o)&0x7) <--- Changed from 0x3
#define ELF64_ST_VISIBILITY(o) ((o)&0x7) <--- Changed from 0x3
Symbol visibility is currently represented by the least significant
2 bits of a symbol's st_other field. Therefore, adding these two
additional values implies a widening of the visibility part of
st_other to three bits (as encapsulated by the ELF[32|64]_ST_VISIBLITY
macros). We feel that it is safe to take another bit from st_other,
as the bit is currently unused and always 0. Old linkers will fail
to understand the new bits, but will continue to understand the
original 4 values. This behavior is to be expected, and is not a
problem, as new applications that use these features will be built
by new linkers.
STV_SINGLETON:
We have a need to ensure that all references to certain symbols bind
to only one instance of a definition. In the old days (when processes
and linking capabilities were much simpler), this requirement was
typically met with simple interposition. For example, if A.so and B.so
both defined the symbol foo(), and a process loaded the objects in the
following order:
main -> A.so -> B.so ....
then any reference to foo() from within the process would bind to the
first definition provided by A.so.
However, life has gotten more complex. Some compiler implementations
instantiate the same template code within multiple dynamic objects.
Sometimes this template code uses private static data, or provides
link-list pointers or such. These duplicates expect to interpose on
one-another, so that all references bind to *one* instance of a
definition. This expectation can be circumvented in a number of ways:
i. dlopen hierarchies can establish local groups that result in
different definitions being bound to from within each group.
ii. scoping technologies that define interface definitions for
dynamic objects can result in "interposing" symbols being
reduced to locals.
iii. technologies such as direct-binding seek to allow objects to
bind to different definitions of the same symbols.
The bottom line is that an "interposing" expectation generated by a
compiler implementation can be compromised by the user's attempt to
control the runtime visibility of a symbol.
Explicitly identifying a symbols visibility as STV_SINGLETON is
intended to ensure that the symbol's global attribute isn't compromised,
and to instruct the runtime environment that only one definition of a
singleton can be bound to from any reference within a process.
This new visibility attribute stands out from the existing definitions
(STV_DEFAULT, STV_PROTECTED, STV_HIDDEN and STV_INTERNAL) in that the
most restrictive visibility can not be applied to any symbol resolution.
STV_ELIMINATE:
We have a need to eliminate symbols from the final dynamic executable
or shared object. We've actually been doing this for some time with
an augmented versioning attribute (VER_NDX_ELIMINATE) which gets
associated with a symbol through a mapfile (eliminate) definition.
We'd like to promote this capability by using the st_other field.
This makes it easier for compilers and third party relocatable object
generators to assign the attribute to a symbol. This capability also
allows non-global symbols to be identified for elimination, which can
not be done via our mapfile technology. Hence this new visibility makes
our present elimination easier, and also enables more cases to be handled.
STV_SINGLETON and STV_ELIMINATE are not directly related. However,
it would be efficient for us to address them both at the same time,
as they are both changes to st_other.
------------------------------------------------------------------------
The ELF ABI document contains an ELF Symbol Visibility table. I
suggest the following update, and associated description:
Name Value
....
STV_SINGLETON 4
STV_ELIMINATE 5
STV_SINGLETON
This visibility attribute ensures that a symbol remains global,
and that a single instance of the symbol definition is bound to
by all references within a process. An STV_SINGLETON can not be
directly bound to.
STV_ELIMINATE
This visibility attribute extends STV_HIDDEN. A symbol that
is defined in the current component as eliminate is not
visible to other components. The symbol is not written to the
symbol table of a dynamic executable or shared object from
which the component is used.
The STV_SINGLETON visibility attribute can affect the resolution of
symbols within an executable or shared object during link-editing.
A STV_SINGLETON can be combined with a STV_DEFAULT visibility
attribute, with the STV_SINGLETON taking precedence. A STV_SINGLETON
can not be combined with any other visibility attribute. Such an
event is deemed fatal to the link-edit.
--
Rod.
