Re: PATCH: Add STB_SECONDARY support

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Sun, Jul 1, 2012 at 11:24 PM, Alan Modra <amodra@gmail.com> wrote:
> On Sat, Jun 30, 2012 at 02:18:41PM -0700, H.J. Lu wrote:
>> This patch adds STB_SECONDARY support. ?I am enclosing the STB_SECONDARY
>> proposal posted on the gABI group. This patch is backward compatible
>> with existing ld.so. ?STB_SECONDARY symbols are generated only with
>> "ld -shared -z secondary" switch. ?OK to install?
>
> I think there are a few problems with this proposal. ?One is that weak
> symbol behaviour is not well defined by the gABI. ?In fact the spec
> says
>
> "The behavior of weak symbols in areas not specified by this document
> is implementation defined. Weak symbols are intended primarily for use
> in system software. Applications using weak symbols are unreliable
> since changes in the runtime environment might cause the execution to
> fail."
>
> Left unspecified is the behaviour of weak symbols in dynamic objects
> at runtime. ?So I think your specification is standing on shaky ground
> when saying anything about runtime behaviour of secondary symbols.
> You really ought to first specify runtime behaviour of weak symbols
> (and trying to do that will likely result in a conflict).

I don't think we can change the weak specification
for the reason you stated above.

> After reading some of the history of your proposal on
> https://groups.google.com/forum/?fromgroups#!forum/generic-abi I see
> that you originally only wanted secondary symbols for relocatable
> objects, but were pushed to specify them more widely by other well-
> meaning but perhaps inexperienced people. ?(I'm not intending any
> insult in that comment, I simply don't know the experience or
> otherwise of people who responded.) ?I also have not seen positive
> comments from anyone I know is experienced in GNU toolchain work.
> Maybe that is simply because I haven't looked far enough, but right
> now I can't see any compelling reason to accept this proposal. ?You
> need to convince me or another global binutils maintainer that
> STB_SECONDARY is a good idea.

It will be used to provide the backup implementation for a new
library function, which will only used if there is no a weak/global
implementation at link-time, so that a software package can use
the new library function to link against both the new and old versions
of  the library.  When linking against the old library, the backup
one will be used and when linking against the new library, the
one in the new library will be used.

As for the run-time behavior, secondary symbol s identical to weak
symbol when LD_DYNAMIC_WEAK is set in glibc:

http://sourceware.org/ml/libc-alpha/2012-06/msg00810.html

This provides the original run-time behavior of weak symbols
in glibc, which has the same backup effect at run-time.

BTW, here is my proposal as the GNU extension:

http://sourceware.org/ml/binutils/2012-04/msg00259.html

I was suggested to make it an extension to gABI.

> If the reason for your proposal still only remains a way of providing
> lower precedence symbols at link time, why can you not get the
> behaviour you want just with weak symbols? ?For example, place all
> your lower precedence weak symbol functions/data in an archive library
> that is linked last? ?That might not be convenient. ?I'm just asking
> whether it would be possible. ?(*) ?If it is possible then no
> extension to the gABI is necessary.

The main usage is

1. ISV defines a secondary symbol in a library.
2. The library with a secondary symbol is used by programmers.

#1 and #2 are different people. ISV has no control over
the command line used by programmers.  We need
a reliable solution which is transparent to programmers,

>
> *) Convenience might be improved by implementing a linker switch that
> says "link this object file as if it were inside an archive library
> placed last on the linker command line".
>


-- 
H.J.