On Thu, Jun 28, 2012 at 6:43 AM, Lowell, Randy <randy.low...@hp.com> wrote:
> This looks good. I just have one wordsmithing comment.
>
> I would have listed the STB_SECONDARY differences in a different
> order -- maybe (3 1 2 4). That puts the most general difference
> first, and it matches the order used for the description of
> STB_WEAK.
Here is the revised proposal.
Thanks.
H.J.
----
We want to provide a relocatable object which can take advantage of all
versions of a supported OS. For a function, foo, in the C library, we
can use it only if it is available on all versions of the C library or
we provide our own implementation of foo. With our own foo, the one in
the C library will never be used. Here is a proposal to add STB_SECONDARY
to gABI to support the secondary definition so that a software vendor
can provide an alternative implementation in case it isn't available
in the C library.
STB_SECONDARY
Secondary symbols are similar to weak symbols, but their definitions
have lower precedence than global and week symbols. The difference
between secondary symbols and weak symbols are
1. The link editor ignores the secondary definition if there is
a global, weak or common definition with the same name. Multiple
secondary definitions with the same name will not cause an error.
The first appearance of the secondary definition should be honored
and the rest are ignored.
2. The link editor must search archive library and extract
archive members to resolve defined and undefined secondary symbol.
3. When the link editor searches a shared object, it must honor
the global or weak definition in the shared object and ignore the
secondary one with the same name.
4. The link editor may treat the secondary definition in the
shared object as a global definition.
The purpose of this symbol binding is to provide the primary
definition as a global, weak or common symbol in an archive library
or a shared object while keeping a secondary definition in a
relocatable object. If there is no primary definition, the
secondary definition will be used.
When secondary definitions become part of an executable or shared
object, linker may convert them to global or local definitions.
At run-time, when resolving a symbol, after seeing a secondary
definition, the dynamic linker must keep searching until a
global or weak definition is found. If a global or weak
definition is found, it will be used to satisfy the symbol lookup.
Otherwise, the secondary definition will be used.
If the dlopen loads a global or weak definition after the program
has already resolved references to a secondary definition, those
references remain bound to the secondary definition. Any
references resolved after the dlopen, for which the dlopened
module is included in the module search list, would be resolved
to the global or weak definition.
STB_SECONDARY is defined as:
#define STB_SECONDARY 3 /* Secondary symbol */
NOTE:
The behavior of secondary symbols in areas not specified by this
proposal is implementation defined.
