This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
RE: Add STB_SECONDARY to gABI
> -----Original Message-----
> From: generic-abi@googlegroups.com [mailto:generic-
> abi@googlegroups.com] On Behalf Of Suprateeka R Hegde
> Sent: Monday, May 14, 2012 12:40 PM
> To: generic-abi@googlegroups.com; 'GCC Development'; 'Binutils'; 'GNU C
> Library'; 'Ansari, Zia'
> Subject: RE: Add STB_SECONDARY to gABI
>
> How about stating that the behavior of
> STB_SECONDARY symbols in areas not specified
> by this proposal matches that of STB_WEAK?
>
> For example, we may not want to go into
> runtime details when an unresolved-hence-zero-valued
> secondary reference (type STT_FUNC) is hit at runtime.
> In such instances let us ride on the existing
> definitions of STB_WEAK.
>
> In that way, we don't have to define
> everything explicitly. Does that look good?
Good idea.
My concern about precedence of weak vs. secondary undefs is
probably just an implementation detail, so I'll withdraw that.
It only comes into play if the implementation creates a merged
list of undefs for all of the input object files and/or load
modules. From the perspective of the gABI, each reference is
handled individually, so we don't need to say anything about
precedence of conflicting undefs.
So I agree with the suggestion to delete difference #5
and add the "otherwise matches STB_WEAK" statement.
Randy
>
> --
> Supra
>
> > -----Original Message-----
> > From: generic-abi@googlegroups.com [mailto:generic-
> > abi@googlegroups.com] On Behalf Of Lowell, Randy
> > Sent: 14 May 2012 07:12 PM
> > To: generic-abi@googlegroups.com; GCC Development; Binutils; GNU C
> > Library; Ansari, Zia
> > Subject: RE: Add STB_SECONDARY to gABI
> >
> > This looks good. I just want to check one thing with you. In point
> > 5
> > you state that unresolved secondary symbols have a zero value. Are
> > you implying that unresolved secondary symbols should not result in
> > a
> > link or load-time error? If that's the case, you should also make
> > it
> > clear that a secondary reference (STB_SECONDARY/SHN_UNDEF) has lower
> > precedence than a global or weak reference.
> >
> > Randy
> >
> > > -----Original Message-----
> > > From: generic-abi@googlegroups.com [mailto:generic-
> > > abi@googlegroups.com] On Behalf Of H.J. Lu
> > > Sent: Saturday, May 12, 2012 9:53 AM
> > > To: Generic System V Application Binary Interface; GCC
> > Development;
> > > Binutils; GNU C Library; Ansari, Zia
> > > Subject: Add STB_SECONDARY to gABI
> > >
> > > Here is the final proposal to add STB_SECONDARY to gABI.
> > > Any comments?
> > >
> > > 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 even lower precedence. The difference between
> > secondary symbols
> > > and weak symbols are
> > >
> > > 1. The link editor must search archive library and extract
> > > archive members to resolve defined and undefined secondary
> > symbol.
> > > 2. 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.
> > > 3. 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.
> > > 4. The link editor may treat the secondary definition in the
> > > shared object as a global definition.
> > > 5. Unresolved secondary symbols have a zero value.
> > >
> > > 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 */
> > >
> > > --
> > > 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.
> >
> > --
> > 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.
>
> --
> 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.