Add STB_SECONDARY to gABI

Suprateeka R Hegde hegdesmailbox@gmail.com
Thu Jun 28 14:35:00 GMT 2012


> -----Original Message-----
> From: generic-abi@googlegroups.com [mailto:generic-
> abi@googlegroups.com] On Behalf Of H.J. Lu
> Sent: 28 June 2012 07:55 PM
> To: generic-abi@googlegroups.com
> Cc: GCC Development; Binutils; GNU C Library; Ansari, Zia
> Subject: Re: Add STB_SECONDARY to gABI
> 
> On Thu, Jun 28, 2012 at 7:12 AM, Suprateeka R Hegde
> <hegdesmailbox@gmail.com> wrote:
> > The write-up looks good.
> >
> > Two typos:
> > 1. An instance of "week" instead of "weak"
> > 2. Some text mention "linker" and some other mention "link
> editor".
> 
> Fixed in the revised proposal.
> 
> > Question: will this be part of the current gABI draft soon?
> >
> 
> That is a good question.  I don't know if the gABI draft is
> being actively maintained at the moment.

Then we have to get it active. What is the process? Or else,
these standards might get accumulated either over emails or
as comments in the tool chain's sources.

--
Supra 

> 
> --
> 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 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.
> 
> --
> 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 generic-abi@googlegroups.com.
> To unsubscribe from this group, send email to generic-
> abi+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/generic-abi?hl=en.



More information about the Binutils mailing list