Proposal to add STB_SECONDAY

58 views
Skip to first unread message

H.J. Lu

unread,
Nov 6, 2013, 11:49:54 AM11/6/13
to John Wolfe, Generic System V Application Binary Interface
Hi John,

We like to have a way to override a symbol definition in a shared object
by another definition in a different shared object at run-time and
override a symbol definition in relocatable object by another
definition in an archive or a shared object at link-time.

Today, the GNU C library allows one to override a weak definition in a
shared object with a global definition in a different shared object at
run-time by defining the environment variable, LD_DYNAMIC_WEAK=1.

It can be used 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.

It can also be used to support static linking with -lpthread in the GNU
C library:

https://sourceware.org/bugzilla/show_bug.cgi?id=5784

without linking in the unused part of libpthread.a.

I am re-sending the final version we discussed in September, 2012:

https://groups.google.com/forum/?hl=en#!topic/generic-abi/tLbPI5mm5iY

Please consider including it in the gABI.

Thanks.

H.J.
----
STB_SECONDARY

Secondary symbols are similar to weak symbols, but their definitions
have lower precedence than global and weak 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, the link editor 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.

Rod Evans

unread,
Nov 6, 2013, 12:57:53 PM11/6/13
to gener...@googlegroups.com, John Wolfe
Could you give a real example of why this is useful?  I always thought WEAK symbols were a terrible idea,
and this seems to make things even more complicated.

A runtime process can potentially load tens/hundreds of dependecies.  Much of this is defered by lazy
loading.  Are you proposing that finding a secondary symbol will cause ld.so.1 to load all possible
dependencies to search for a better variant?  That would be expensive, and isn't something we do for
WEAK symbols anyway.

Why can't interposition be used to "overload" an existing symbol (if that's what you are trying to achieve)?



--
You received this message because you are subscribed to the Google Groups "Generic System V Application Binary Interface" group.
To unsubscribe from this group and stop receiving emails from it, send an email to generic-abi...@googlegroups.com.
To post to this group, send email to gener...@googlegroups.com.
Visit this group at http://groups.google.com/group/generic-abi.
For more options, visit https://groups.google.com/groups/opt_out.



--
----
Rod.

John Wolfe

unread,
Nov 7, 2013, 4:00:40 PM11/7/13
to gener...@googlegroups.com
H.J.

You stated at the close of your Sept 2012 e-mail that "The final spec for STB_SECONDARY is done.  But many people have doubts on its usefulness".

I share Rod's concerns that the spec, as it has evolved, implies an expensive runtime hit.   Also it would make every current linker and runtime loader non-conformant.

A real example could go a long way in convincing others.

In the meantime, I will review the 40+ previous posts on this subject.

-- John
Reply all
Reply to author
Forward
0 new messages