public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Ian Lance Taylor <ian@zembu.com>
To: hjl@lucon.org
Cc: hjl@lucon.org, rth@twiddle.net, geoffk@ozemail.com.au,
	drepper@cygnus.com, binutils@sourceware.cygnus.com,
	jgg@ualberta.ca
Subject: Re: A glibc dynamic linker or gld bug?
Date: Wed, 07 Jul 1999 07:44:00 -0000	[thread overview]
Message-ID: <19990707144318.29700.qmail@daffy.airs.com> (raw)
In-Reply-To: <19990707143901.2022657BA@ocean.lucon.org>

   Date: Wed, 7 Jul 1999 07:39:01 -0700 (PDT)
   From: hjl@lucon.org (H.J. Lu)

   >    > As far as I can see, this can only happen if all relocations involving
   >    > the weak defined symbol are copied into the executable as dynamic
   >    > relocations.
   > 
   >    What if the definition in executable is strong? Do you have the same
   >    problem? I don't think we should worry about this.
   > 
   > No, we don't have the same problem if the definition in the executable
   > is strong, because in that case the shared library will never override
   > the definition.  The only time a shared library can override a
   > definition is if it is weak in the executable.

   By "problem", I mean the same symbol will have different values in
   executable and DSO. When you update one of them, you won't see the
   change in the other. If you relink executable against the new DSO,
   the symbol in executable will override the one in DSO.

I guess I don't understand.  The DSO should have relocations for all
uses of the symbol, so it will wind up seeing the definition in the
executable.  At runtime the symbol will not have different values.
This is an ordinary case in which the executable overrides the DSO.

As far as I know, the only way you can get a DSO to see a different
value from the main executable is to use -Bsymbolic or version
scripts.  Also, you have just reported a case in which it happens due
to the use of weak defined symbols in the executable.  But there
definitely should not be any way to make the DSO and the executable
see a different value for a strong defined symbol.

Ian

  reply	other threads:[~1999-07-07  7:44 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-07-04 13:52 H.J. Lu
1999-07-05  2:38 ` Geoff Keating
1999-07-05  7:41   ` Jason Gunthorpe
1999-07-05 20:48   ` Richard Henderson
1999-07-06  1:01     ` Geoff Keating
1999-07-06 12:16       ` Geoff Keating
1999-07-06 19:11     ` Ian Lance Taylor
1999-07-06 19:28       ` Richard Henderson
1999-07-06 19:31         ` Ian Lance Taylor
1999-07-06 21:45       ` H.J. Lu
1999-07-07  7:36         ` Ian Lance Taylor
1999-07-07  7:39           ` H.J. Lu
1999-07-07  7:44             ` Ian Lance Taylor [this message]
1999-07-07  7:57               ` H.J. Lu
1999-07-07  8:03                 ` Ian Lance Taylor
1999-07-07 20:12               ` Geoff Keating
1999-07-07 20:16                 ` Ian Lance Taylor
1999-07-07  1:33       ` Geoff Keating
1999-07-07  7:35         ` Ian Lance Taylor
1999-07-07 11:22         ` Ian Lance Taylor
1999-07-07 20:13           ` Geoff Keating
1999-07-07 20:28             ` Ian Lance Taylor
1999-07-08 17:29               ` Geoff Keating
1999-07-09  6:11                 ` Franz Sirl
1999-07-10  3:14                   ` Geoff Keating
1999-07-10  5:40                     ` Ian Lance Taylor

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=19990707144318.29700.qmail@daffy.airs.com \
    --to=ian@zembu.com \
    --cc=binutils@sourceware.cygnus.com \
    --cc=drepper@cygnus.com \
    --cc=geoffk@ozemail.com.au \
    --cc=hjl@lucon.org \
    --cc=jgg@ualberta.ca \
    --cc=rth@twiddle.net \
    /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).