Add STB_SECONDARY to gABI

[H.J. Lu]

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 */

[Lowell, Randy]

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

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

[Suprateeka R Hegde]

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?

--
Supra

[Suprateeka R Hegde]

> -----Original Message-----
> From: gener...@googlegroups.com [mailto:generic-

> a...@googlegroups.com] On Behalf Of Lowell, Randy
> Sent: 14 May 2012 07:12 PM

> To: gener...@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.

In this case we should just mention that "secondary reference (STB_SECONDARY/SHN_UNDEF) has lower precedence than a global or weak reference". We cannot keep point number 5 (as it appears now) under differences because gABI already says "Unresolved weak symbols
have a zero value". So either remove point number 5 under differences or change it to something discussed above.

--
Supra

[Lowell, Randy]

> -----Original Message-----
> From: gener...@googlegroups.com [mailto:generic-
> a...@googlegroups.com] On Behalf Of Suprateeka R Hegde
> Sent: Monday, May 14, 2012 12:40 PM
> To: gener...@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

[H.J.]

Hi,

Here is the updated proposal.  Does it look OK?

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 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.

      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.

[H.J. Lu]

Hi,

Resending with plain text.

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 lower precedence than global and week symbols. 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.

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.

[Lowell, Randy]

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.

Randy

> -----Original Message-----
> From: gener...@googlegroups.com [mailto:generic-
> a...@googlegroups.com] On Behalf Of H.J. Lu

[H.J. Lu]

On Thu, Jun 28, 2012 at 6:43 AM, Lowell, Randy <Randy....@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.

[Suprateeka R Hegde]

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".

Question: will this be part of the current gABI draft soon?

--
Supra

> -----Original Message-----
> From: gener...@googlegroups.com [mailto:generic-
> a...@googlegroups.com] On Behalf Of H.J. Lu
> Sent: 28 June 2012 07:30 PM
> To: gener...@googlegroups.com
> Cc: GCC Development; Binutils; GNU C Library; Ansari, Zia
> Subject: Re: Add STB_SECONDARY to gABI
>

[H.J. Lu]

On Thu, Jun 28, 2012 at 7:12 AM, Suprateeka R Hegde
<hegdes...@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.

--
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

[Suprateeka R Hegde]

> -----Original Message-----
> From: gener...@googlegroups.com [mailto:generic-
> a...@googlegroups.com] On Behalf Of H.J. Lu
> Sent: 28 June 2012 07:55 PM
> To: gener...@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
> <hegdes...@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. Lu]

On Thu, Jun 28, 2012 at 7:34 AM, Suprateeka R Hegde

<hegdes...@gmail.com> wrote:
>> -----Original Message-----
>> From: gener...@googlegroups.com [mailto:generic-
>> a...@googlegroups.com] On Behalf Of H.J. Lu
>> Sent: 28 June 2012 07:55 PM
>> To: gener...@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
>> <hegdes...@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.
>

Can someone take gABI draft html files and put them on
github?


--
H.J.

[Joseph S. Myers]

On Thu, 28 Jun 2012, H.J. Lu wrote:

> Can someone take gABI draft html files and put them on
> github?

That requires permission from the copyright holder.

--
Joseph S. Myers
jos...@codesourcery.com

[Mats Wichmann]

On 06/28/2012 08:44 AM, Joseph S. Myers wrote:
> On Thu, 28 Jun 2012, H.J. Lu wrote:
>
>> Can someone take gABI draft html files and put them on
>> github?
>
> That requires permission from the copyright holder.

Is it even clear who that is now? One would say this was in the area
that was in contention in the now completed lawsuit?

http://www.sco.com/developers/gabi/latest/contents.html

is the "best" location I know about.

[Ali Bahrami]

   I was comparing the Linux <elf.h> and the gABI with the Solaris headers
today, in order to bring us back in sync.I don't see STB_SECONDARY
in the latest gABI

    http://www.sco.com/developers/gabi/latest/contents.html

or in the Linux <elf.h>.  Is Is this proposal still going to happen?

I see some question about where to send such requests --- I'm currently
in the process of putting forward another gABI proposal, and I found that

regi...@uxsglobal.com or regi...@sco.com are still
active (these are aliases of each other). You might want
to send mail there.

[Joseph S. Myers]

On Mon, 24 Sep 2012, Ali Bahrami wrote:

> I was comparing the Linux <elf.h> and the gABI with the Solaris headers
> today, in order to bring us back in sync.I don't see STB_SECONDARY

The Linux (glibc) elf.h

http://sourceware.org/git/?p=glibc.git;a=blob;f=elf/elf.h;hb=HEAD

to a large extent just has definitions relevant to the dynamic linker,
rather than those only relevant at static link time or to other tools;
certainly that's the case for more recently added definitions, they will
largely have been added only where needed for the dynamic linker. The GNU
binutils headers

http://sourceware.org/git/?p=binutils.git;a=tree;f=include/elf;hb=HEAD

may be of more use in identifying definitions that are in use, but not by
the dynamic linker.

[Cary Coutant]

> I was comparing the Linux <elf.h> and the gABI with the Solaris headers
> today, in order to bring us back in sync.I don't see STB_SECONDARY
> in the latest gABI
>
> http://www.sco.com/developers/gabi/latest/contents.html
>
> or in the Linux <elf.h>. Is Is this proposal still going to happen?

I don't think that we've yet reached a consensus on that proposal.

-cary

[Suprateeka R Hegde]

I see that the final proposal was drafted after several discussions and
the only thing pending was to add it to gABI. H.J would have better
clarity on the status of the final proposal, I believe.

--
Supra

>
> -cary
>

[H.J. Lu]

The final spec of STB_SECONDARY is done. But many people have
doubts on its usefulness.


--
H.J.