|
Description
|
Various projects have been paving the way to enable direct-bindings to be fully
enabled within the OSnet environment (see 4947191). However, an existing thorny
issue has been the interaction with C++. The C++ implementation requires a number
of interfaces to be "interposed" upon, such that only one definition of a multiply
defined symbol is bound to from all references within a process.
This C++ requirement has already been broken with a number of existing link-editing
techniques. Nothing stops users from using mapfiles to localize a number of their
interfaces, or applying flags like -Bsymbolic, in an attempt to reduce their
relocation overhead. These techniques however, distroy the interposition
expectation and have caused no end of user problems.
If the OSnet was built to employ direct bindings, this would be quite a visible
advertisement, which may trigger C++ users to experiment with direct bindings.
The use of direct bindings with C++ interfaces is going to compound their issues
with interposition requirements.
To prepare for direct bindings, and to provide a more robust C++ framework to
ensure their interposition requirements are met, the C++ folks have asked for a new
symbol visibility. This visibility, expressed as an ELF_ST_VISIBILITY() value
within a symbols st_other field, is defined STV_SINGLETON. Effectively, this
symbol visibility will ensure that only one instance (typically the first instance
encountered from an object loaded within a process) of a symbol will be bound to from
any reference - no matter what versioning/scoping/binding modes are also employed
to construct an object.
The Dtrace folks have long been asking for a symbol that can be used to relocate
multiple objects together, but can be removed from the final object created by ld(1).
Although the mapfile ELIMINATE directive has been around for some time, and can
achieve this goal, it would be simpler for the overall build architecture if this
requirement could be defined together with a symbol definition. So, while we're
looking at STV_SINGLETON, we thought we'd throw in STV_ELIMINATE too. This
visibility is the same as STV_HIDDEN, but with the added feature that the symbol
will not find it's way into any symbol table within the final object built by ld(1).
As we're planning on using a public element of the symbol table entry (st_other),
a conversation with various other ELF vendors has been conducted. See:
http://groups.google.com/group/generic-abi/browse_thread/thread/1a84adc15666164
It turns out SCO have been using an addition visibility, STV_EXPORTED, for some
time, and thus our final proposal is to incorporate their visibility and the two
we want by defining the following new visibilities for Solaris (sys/elf.h):
#define STV_EXPORTED 4
#define STV_SINGLETON 5
#define STV_ELIMINATE 6
#define ELF32_ST_VISIBILITY(o) ((o)&0x7) <--- Changed from 0x3
#define ELF64_ST_VISIBILITY(o) ((o)&0x7) <--- Changed from 0x3
The google/abi discussion eventually petered out, without any calls to disallow
the addition of these new visibilities.
|
