The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Rob Gingell <gingell@computer.org>
To: Paul Winalski <paul.winalski@gmail.com>,
	The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: Re: [TUHS] History of symbol preemption
Date: Mon, 13 Jan 2020 18:53:33 -0800	[thread overview]
Message-ID: <5e9784ef-155a-6982-50dc-73a863b13028@computer.org> (raw)
In-Reply-To: <CABH=_VTOhJ57t-iWkcV9KYoSmDjy-6-6-sUTVYz-nJDTrprHjw@mail.gmail.com>

On 1/13/2020 11:58 AM, Paul Winalski wrote:
> When was symbol preemption when loading shared objects first
> implemented in Unix?  Are there versions of Unix that don't do symbol
> preemption?

The behavior described was in dynamic linking as introduced in SunOS 
4.0. There had been a couple of earlier shared library implementations, 
notably System V Shared Libraries but I couldn't speak to whether any of 
them had the behavior.

The reason the behavior is present is to (try to) preserve the behavior 
of an "ld" command line with respect to how the order of library 
specification impacted which definition of a given symbol was used to 
resolve references to it. With archive libraries the ordering could be 
used to effect interposition in sometimes obscure and questionable ways 
especially when archives were unordered. With shared objects, given that 
the whole object is always present, the usual intent of the ordering of 
libraries with respect to interposition is preserved by having the first 
definition be used to resolve all references.

(And the reason "ld"'s behavior was relevant is that the idea was to 
make link editing an ongoing process as code assembled rather than a one 
time thing. So yes the run-time link-editor does it but that's because 
it's conceptually the functionality of the static link-editor continuing 
its work to knit together the still-assembling program.)

The evolution of link editors in Solaris eventually resulted in the 
ability to effect more granular scoping and binding operations, 
including shared objects whose references to internal symbols could not 
be interposed upon and thus perhaps reflected the behavior of other 
systems mentioned in the original question.

But the interposition / preemption behavior was the one which, at the 
time dynamic linking was introduced, best satisfied the "Principle of 
Least Surprise".

On 1/13/2020 12:46 PM, Rico Pajarola wrote:
> I believe a good proxy for 
> finding anything that inherited from or was inspired by this is a linker 
> that recognizes LD_PRELOAD.

On 1/13/2020 2:20 PM, Larry McVoy wrote:
> You could, and people did, make a shared lib that overloaded
> the default gethostbyname(3) that wanted to do YP, the lib would provide
> a DNS based one instead.

Handling interposition in this way turned it into an explicit feature. 
Once multiple definitions for a symbol could exist in a program (or, 
definitions not yet referenced), devices to permit the navigation of the 
interposition like LD_PRELOAD, or the Name Service Switch, or Pluggable 
Authentication Modules became things that could be built around the 
functionality.

On 1/13/2020 1:04 PM, Clem Cole wrote:
> @ Rico I'm failing sure ELF came from AT&T Summit, not Sun.

Yes, SunOS 4.0 rode the a.out object file format. ELF originated at 
Summit and as others have noted was a vast improvement.

  parent reply	other threads:[~2020-01-14  2:54 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-13 19:58 Paul Winalski
2020-01-13 20:46 ` Rico Pajarola
2020-01-13 21:04   ` Clem Cole
2020-01-13 21:40     ` Rico Pajarola
2020-01-13 21:44       ` Paul Winalski
2020-01-13 21:45         ` Rico Pajarola
2020-01-13 22:20           ` Larry McVoy
2020-01-13 21:42     ` Paul Winalski
2020-01-13 22:53       ` Henry Bent
2020-01-14  0:31         ` Clem Cole
2020-01-14  2:53 ` Rob Gingell [this message]
2020-01-14 19:21 ` [TUHS] two AIX items [was " Charles H Sauer
2020-01-14 20:31   ` Clem Cole
2020-01-14 23:22   ` Kevin Bowling
2020-01-15 16:41   ` Paul Winalski

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=5e9784ef-155a-6982-50dc-73a863b13028@computer.org \
    --to=gingell@computer.org \
    --cc=paul.winalski@gmail.com \
    --cc=tuhs@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).