The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Paul Winalski <paul.winalski@gmail.com>
To: ron@ronnatalie.com
Cc: tuhs@minnie.tuhs.org
Subject: Re: [TUHS] Deleted lib1 and lib2 in v6, recoverable?
Date: Sun, 30 Dec 2018 14:02:03 -0500	[thread overview]
Message-ID: <CABH=_VRY_jiwekcut7HoEg0MH+a5ThNYkPuuC2Gm8tDsjhv3Ug@mail.gmail.com> (raw)
In-Reply-To: <128301d4a070$4794ea70$d6bebf50$@ronnatalie.com>

On 12/30/18, ron@ronnatalie.com <ron@ronnatalie.com> wrote:
> Yes, it pretty much has to be this way as it is a single pass process and
> the ar format is simple.

Early ld only made a single pass over each library on the command
line?  Interesting.  Most linkers (all modern ones?) make repeated
passes over a library until a pass doesn't resolve any symbols; only
then does the linker go on to the next library or object module on the
command line.  A single pass link makes some sense, though, on a
resource-constrained system--it's easier to implement, and a
multi-pass link has O(N**2) worst-case behavior.

ranlib greatly speeds up the link process, but early implementations
of ranlib had a problem (I would call it a bug):  they indexed common
symbols as well as globals.  Common symbol semantics require that if
an undefined external resolves against a common symbol, that in itself
is not enough to cause the object module to be loaded.  So even with
ranlib it's necessary for the linker to process the symbol table of
each module that gets a hit when the ranlib index is processed, and to
ignore instances where the resolution is against a common symbol.  ld
had a bug in this area that caused common symbol sizes to be maximized
improperly, and one of the stdio modules had a dependency on this bug.
Later versions of UNIX didn't have this bug; I don't know whether it
was ld or the stdio module that was fixed (I suspect the latter).

-Paul W.

  parent reply	other threads:[~2018-12-30 19:02 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-29  1:09 Noel Chiappa
2018-12-29  1:26 ` Will Senn
2018-12-29  1:35 ` Warren Toomey
     [not found]   ` <82e23dba-38a4-3ee4-e35a-6293b8eef749@gmail.com>
2018-12-29  4:59     ` Warren Toomey
2018-12-29 16:26       ` Clem Cole
2018-12-29 16:49         ` Warner Losh
2018-12-29 17:48           ` Clem cole
2018-12-30 18:34 ` Paul Winalski
2018-12-30 18:48   ` ron
2018-12-30 18:56     ` Warner Losh
2018-12-30 19:02     ` Paul Winalski [this message]
2018-12-31  0:00   ` Donald ODona
2018-12-31 17:51     ` Paul Winalski
  -- strict thread matches above, loose matches on Subject: below --
2018-12-31  3:22 Rudi Blom
2018-12-31  2:28 Doug McIlroy
2018-12-31  3:34 ` Will Senn
2018-12-31  6:52   ` ron
2018-12-30 19:07 Norman Wilson
2018-12-30 19:24 ` Paul Winalski
2018-12-31  6:57 ` arnold
2019-01-02 13:54   ` Tony Finch
2018-12-29 14:13 Noel Chiappa
2018-12-29  0:25 Will Senn

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='CABH=_VRY_jiwekcut7HoEg0MH+a5ThNYkPuuC2Gm8tDsjhv3Ug@mail.gmail.com' \
    --to=paul.winalski@gmail.com \
    --cc=ron@ronnatalie.com \
    --cc=tuhs@minnie.tuhs.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 NNTP newsgroup(s).