This is the mail archive of the
mailing list for the binutils project.
RE: Add STB_SECONDARY to gABI
The write-up looks good.
1. An instance of "week" instead of "weak"
2. Some text mention "linker" and some other mention "link editor".
Question: will this be part of the current gABI draft soon?
> -----Original Message-----
> From: email@example.com [mailto:generic-
> firstname.lastname@example.org] On Behalf Of H.J. Lu
> Sent: 28 June 2012 07:30 PM
> To: email@example.com
> Cc: GCC Development; Binutils; GNU C Library; Ansari, Zia
> Subject: Re: Add STB_SECONDARY to gABI
> On Thu, Jun 28, 2012 at 6:43 AM, Lowell, Randy <Randy.Lowell@hp.com>
> > 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.
> We want to provide a relocatable object which can take advantage of
> versions of a supported OS. For a function, foo, in the C library,
> can use it only if it is available on all versions of the C library
> we provide our own implementation of foo. With our own foo, the one
> the C library will never be used. Here is a proposal to add
> to gABI to support the secondary definition so that a software
> can provide an alternative implementation in case it isn't available
> in the C library.
> Secondary symbols are similar to weak symbols, but their
> have lower precedence than global and week symbols. The
> 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.
> secondary definitions with the same name will not cause an
> The first appearance of the secondary definition should be
> and the rest are ignored.
> 2. The link editor must search archive library and extract
> archive members to resolve defined and undefined secondary
> 3. When the link editor searches a shared object, it must
> the global or weak definition in the shared object and ignore
> 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
> 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
> object, linker may convert them to global or local
> 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
> Otherwise, the secondary definition will be used.
> If the dlopen loads a global or weak definition after the
> has already resolved references to a secondary definition,
> 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
> to the global or weak definition.
> STB_SECONDARY is defined as:
> #define STB_SECONDARY 3 /* Secondary symbol */
> The behavior of secondary symbols in areas not specified by
> proposal is implementation defined.
> You received this message because you are subscribed to the Google
> Groups "Generic System V Application Binary Interface" group.
> To post to this group, send email to firstname.lastname@example.org.
> To unsubscribe from this group, send email to generic-
> For more options, visit this group at