public inbox for gas2@sourceware.org
 help / color / mirror / Atom feed
From: Richard Stallman <rms@gnu.ai.mit.edu>
To: ian@cygnus.com
Cc: drepper@cygnus.com, dm@sgi.com, gcc2@cygnus.com, gas2@cygnus.com
Subject: Re: global vars and symbol visibility for mips32/elf
Date: Sun, 11 Aug 1996 01:44:00 -0000	[thread overview]
Message-ID: <199608110844.EAA22234@psilocin.gnu.ai.mit.edu> (raw)
In-Reply-To: <9608110241.AA22482@tweedledumb.cygnus.com>

    If a shared library defines a function foo, and your program defines a
    function foo, that does not cause any conflict.  Your program's
    definition of foo is used.  If functions in the shared library call
    foo, they will call your program's definition of foo rather than the
    shared library's definition.  In this sense, shared libraries act just
    like archive libraries.

This is not, in general, what archive libraries do.  Archive libraries
do this in the common case where each defined global is in a separate
member.  But if one member defines two different globals, the archive
library does not work this way.  It is good practice, in most
situations, to put each global definition into a separate member, but
it is not universal practice.

If one member defines two global symbols X and Y, you can have a
program which links with no complaint against the shared library, but
would get an error if linked against the archive library.  All the
program needs to do is reference X and define Y as weak.  The archive
library would define Y and thus override the weak definition from the
program.  The shared library would, I expect, let the program override
Y's definition.

I think we should make the shared library work just like the archive
in all cases.

What is needed is a table of implications:
  If symbol foo is referenced, treat symbol bar as strong.
  If symbol bar is referenced, treat symbol foo as strong.
  If symbol quux is referenced, treat symbols foo and bar as strong.
  ...

(In that example, I've assumed that one member defines both foo and
bar, while another member defines quux and references foo.)

This table would selectively override the default behavior, which is
the same as now (each defined global symbol in the shared library acts
as weak).

Given this table, there would be no need to do anything special for
common symbols.  A common symbol in the library could be treated just
like any other definition in the library: use it to resolve an
undefined reference, or if forced by the table due to a reference to
some other symbol.

I don't think this would make linking much slower.  I think it could
be made quite fast by means of a table that parallels the main symbol
table in the library, so that you reference it using the same index
used in the main symbol table, rather than by looking up names,


  parent reply	other threads:[~1996-08-11  1:44 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-08-09  2:46 David S. Miller
1996-08-09  5:24 ` David S. Miller
1996-08-09  9:01   ` Ian Lance Taylor
1996-08-09  8:30 ` Ian Lance Taylor
1996-08-09 13:13   ` Ulrich Drepper
1996-08-09 15:30     ` Ian Lance Taylor
1996-08-10 17:37       ` Richard Stallman
1996-08-10 19:41         ` Ian Lance Taylor
1996-08-10 23:26           ` Jim Wilson
1996-08-11  1:44           ` Richard Stallman [this message]
1996-08-13 10:58           ` Ruediger Helsch
1996-08-13 13:36             ` Jim Wilson
1996-08-13 16:06               ` Ruediger Helsch
1996-08-13 19:04                 ` Jim Wilson
1996-08-13 21:02                   ` Richard Stallman
1996-08-14  3:06                     ` Ruediger Helsch
1996-08-14 23:44                       ` Richard Stallman
1996-08-14  0:18                 ` Nick Ing-Simmons
1996-08-14  3:06                   ` Ruediger Helsch
1996-08-15 11:24                   ` H.J. Lu
1996-08-13  9:06 ` Ruediger Helsch
1996-08-13 10:58   ` Richard Stallman
1996-08-13 13:36     ` Ruediger Helsch
1996-08-13 13:36       ` Richard Stallman
1996-08-13 14:40       ` H.J. Lu
1996-08-13 16:06       ` Ulrich Drepper
1996-08-13 16:06         ` Joe Buck
1996-08-13 17:02         ` Rohan LENARD

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=199608110844.EAA22234@psilocin.gnu.ai.mit.edu \
    --to=rms@gnu.ai.mit.edu \
    --cc=dm@sgi.com \
    --cc=drepper@cygnus.com \
    --cc=gas2@cygnus.com \
    --cc=gcc2@cygnus.com \
    --cc=ian@cygnus.com \
    /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).