public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "H.J. Lu" <hjl.tools@gmail.com>
To: binutils@sourceware.org, GNU C Library <libc-alpha@sourceware.org>
Subject: Re: PATCH: Add STB_SECONDARY support
Date: Tue, 10 Jul 2012 07:58:00 -0000	[thread overview]
Message-ID: <CAMe9rOrMiBPHwo0mmwVsQ1Cc5ULTfaLgk5xK7BERZXQwQf5Kdg@mail.gmail.com> (raw)
In-Reply-To: <20120710070451.GH3117@bubble.grove.modra.org>

On Tue, Jul 10, 2012 at 12:04 AM, Alan Modra <amodra@gmail.com> wrote:
> On Wed, Jul 04, 2012 at 07:00:38AM -0700, H.J. Lu wrote:
>> On Tue, Jul 3, 2012 at 5:39 PM, Alan Modra <amodra@gmail.com> wrote:
>> > Like I said, I'm sure you could devise a way to put your backup
>> > functions in another shared library that is searched after libc.so.6
>> > That's dead easy.  Deeper nesting of shared libraries is a little more
>> > difficult, due to breadth first library search, but still possible for
>> > any given depth of libraries.  I imagine this case would be rare
>> > anyway.
>>
>> Sure, we can do it on glibc with LD_DYNAMIC_WEAK.
>> But I haven't found another easy way to achieve the same
>> result
>
> You don't need LD_DYNAMIC_WEAK with the scheme I proposed.  The normal
> ELF shared library symbol resolution works.  The only difficulty is in
> ensuring a backup library is searched last.

Search order isn't easily controlled and glibc already supports
LD_DYNAMIC_WEAK.

>> STB_SECONDARY is my proposal and we have found
>> some nice usages.
>
> Well, STB_SECONDARY allows you to put your backup functions anywhere.
>
> Other than that I see no advantage.  In fact, I think there are a
> whole lot of disadvantages to the whole tool-chain needing to know
> about another symbol binding.  For instance, won't users need to
> compile their code differently?  And if you're marking source with
> attributes, what happens when users manage to make only part of a
> compilation unit secondary?  How does this new binding play with C++?
> We know from past experience that there is a whole world of pain with
> mismatched libstdc++.so and inline functions.  I see STB_SECONDARY as
> another way to get things wrong.  Sorry.
>

STB_SECONDARY should be mainly used by compiler writers and
library developers.  It should be transparent to end users.

As of partial secondary compilation, secondary is only applied to
definition.  You only need to apply secondary to backup definition.
You can provide backup C++ class definition, which should be applied
to the whole class.  The only difference is secondary will make it
dynamic weak.


-- 
H.J.

      reply	other threads:[~2012-07-10  7:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-30 21:19 H.J. Lu
2012-07-02  6:24 ` Alan Modra
2012-07-02 13:31   ` H.J. Lu
2012-07-03  8:26     ` Alan Modra
2012-07-03 11:39       ` H.J. Lu
2012-07-03 14:31         ` Alan Modra
2012-07-03 16:26           ` H.J. Lu
2012-07-03 23:45             ` Alan Modra
2012-07-04  0:19               ` H.J. Lu
2012-07-04  0:39                 ` Alan Modra
2012-07-04 14:00                   ` H.J. Lu
2012-07-10  7:05                     ` Alan Modra
2012-07-10  7:58                       ` H.J. Lu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMe9rOrMiBPHwo0mmwVsQ1Cc5ULTfaLgk5xK7BERZXQwQf5Kdg@mail.gmail.com \
    --to=hjl.tools@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).