14 Jan
2020
14 Jan
'20
1:58 a.m.
The Executable and Linkable Format (ELF) is the modern standard for
object files in Unix and Unix-like OSes (e.g., Linux), and even for
OpenVMS. LInux, AIX and probably other implementations of ELF have a
feature in the runtime loader called symbol preemption. When loading
a shared library, the runtime loader examines the library's symbol
table. If there is a global symbol with default visibility, and a
value for that symbol has already been loaded, all references to the
symbol in the library being loaded are rebound to the existing
definition. The existing value thus preempts the definition in the
library.
I'm curious about the history of symbol preemption. It does not exist
in other implementations of shared libraries, such as IBM OS/370 and
its descendants, OpenVMS, and Microsoft Windows NT. ELF apparently
was designed in the mid-1990s. I have found a copy of the System V
Application Binary Interface from April 2001 that describes symbol
preemption in the section on the ELF symbol table.
When was symbol preemption when loading shared objects first
implemented in Unix? Are there versions of Unix that don't do symbol
preemption?
-Paul W.
14 Jan
14 Jan
2:46 a.m.
This seems to have originated with SunOS 4. I believe a good proxy for
finding anything that inherited from or was inspired by this is a linker
that recognizes LD_PRELOAD. I wonder if there are other independent
implementations in the Unix space.
On Mon, Jan 13, 2020 at 11:59 AM Paul Winalski <paul.winalski(a)gmail.com>
wrote:
The Executable and Linkable Format (ELF) is the modern
standard for
object files in Unix and Unix-like OSes (e.g., Linux), and even for
OpenVMS. LInux, AIX and probably other implementations of ELF have a
feature in the runtime loader called symbol preemption. When loading
a shared library, the runtime loader examines the library's symbol
table. If there is a global symbol with default visibility, and a
value for that symbol has already been loaded, all references to the
symbol in the library being loaded are rebound to the existing
definition. The existing value thus preempts the definition in the
library.
I'm curious about the history of symbol preemption. It does not exist
in other implementations of shared libraries, such as IBM OS/370 and
its descendants, OpenVMS, and Microsoft Windows NT. ELF apparently
was designed in the mid-1990s. I have found a copy of the System V
Application Binary Interface from April 2001 that describes symbol
preemption in the section on the ELF symbol table.
When was symbol preemption when loading shared objects first
implemented in Unix? Are there versions of Unix that don't do symbol
preemption?
-Paul W.
3:04 a.m.
@ Rico I'm failing sure ELF came from AT&T Summit, not Sun.
@ Steve Johnson were you the manager when was created or were you folks
still using COFF?
Anyway... There were issues with COFF WRT being
architecture-independent and supporting dynamic loading well. Steve Rago
would also be a good person to ask if you want some of the details. At one
point there was a COFF2 document, but it may have been System Vx licenses
only. Also, one of the issues was that AT&T had officially tied up COFF
as a proprietary format -- all part of the 'consider it standard' trying to
force their lunch down all the other UNIX systems throat which was not
having it. As a result, CMU's MachO was about to become the default
format (OSF and Apple were already using it for that reason), and Unix
International stepped in and convinced AT&T to released the ELF documents
(I was on the UI technical board at that point). I'm not sure how/why OSF
decided to back off, maybe because after ELF became public it got supported
by GCC.
Now my memory is a little hazy... I think OSF/1-386 used MachO originally,
but I've forgotten. Switching the kernel to use ELF was one of the
differences between OSF1 and Tru64 IIRC.
On Mon, Jan 13, 2020 at 3:47 PM Rico Pajarola <rp(a)servium.ch> wrote:
This seems to have originated with SunOS 4. I believe
a good proxy for
finding anything that inherited from or was inspired by this is a linker
that recognizes LD_PRELOAD. I wonder if there are other independent
implementations in the Unix space.
On Mon, Jan 13, 2020 at 11:59 AM Paul Winalski <paul.winalski(a)gmail.com>
wrote:
The Executable and Linkable Format (ELF) is the
modern standard for
object files in Unix and Unix-like OSes (e.g., Linux), and even for
OpenVMS. LInux, AIX and probably other implementations of ELF have a
feature in the runtime loader called symbol preemption. When loading
a shared library, the runtime loader examines the library's symbol
table. If there is a global symbol with default visibility, and a
value for that symbol has already been loaded, all references to the
symbol in the library being loaded are rebound to the existing
definition. The existing value thus preempts the definition in the
library.
I'm curious about the history of symbol preemption. It does not exist
in other implementations of shared libraries, such as IBM OS/370 and
its descendants, OpenVMS, and Microsoft Windows NT. ELF apparently
was designed in the mid-1990s. I have found a copy of the System V
Application Binary Interface from April 2001 that describes symbol
preemption in the section on the ELF symbol table.
When was symbol preemption when loading shared objects first
implemented in Unix? Are there versions of Unix that don't do symbol
preemption?
-Paul W.
3:40 a.m.
On Mon, Jan 13, 2020 at 1:04 PM Clem Cole <clemc(a)ccc.com> wrote:
@ Rico I'm failing sure ELF came from AT&T
Summit, not Sun.
yes, but unless my memory is playing tricks, SunOS a.out had this feature.
@ Steve Johnson were you the manager when was created
or were you folks
still using COFF?
Anyway... There were issues with COFF WRT being
architecture-independent and supporting dynamic loading well. Steve Rago
would also be a good person to ask if you want some of the details. At one
point there was a COFF2 document, but it may have been System Vx licenses
only. Also, one of the issues was that AT&T had officially tied up COFF
as a proprietary format -- all part of the 'consider it standard' trying to
force their lunch down all the other UNIX systems throat which was not
having it. As a result, CMU's MachO was about to become the default
format (OSF and Apple were already using it for that reason), and Unix
International stepped in and convinced AT&T to released the ELF documents
(I was on the UI technical board at that point). I'm not sure how/why OSF
decided to back off, maybe because after ELF became public it got supported
by GCC.
Now my memory is a little hazy... I think OSF/1-386 used MachO originally,
but I've forgotten. Switching the kernel to use ELF was one of the
differences between OSF1 and Tru64 IIRC.
On Mon, Jan 13, 2020 at 3:47 PM Rico Pajarola <rp(a)servium.ch> wrote:
> This seems to have originated with SunOS 4. I believe a good proxy for
> finding anything that inherited from or was inspired by this is a linker
> that recognizes LD_PRELOAD. I wonder if there are other independent
> implementations in the Unix space.
>
>
> On Mon, Jan 13, 2020 at 11:59 AM Paul Winalski <paul.winalski(a)gmail.com>
> wrote:
>
>> The Executable and Linkable Format (ELF) is the modern standard for
>> object files in Unix and Unix-like OSes (e.g., Linux), and even for
>> OpenVMS. LInux, AIX and probably other implementations of ELF have a
>> feature in the runtime loader called symbol preemption. When loading
>> a shared library, the runtime loader examines the library's symbol
>> table. If there is a global symbol with default visibility, and a
>> value for that symbol has already been loaded, all references to the
>> symbol in the library being loaded are rebound to the existing
>> definition. The existing value thus preempts the definition in the
>> library.
>>
>> I'm curious about the history of symbol preemption. It does not exist
>> in other implementations of shared libraries, such as IBM OS/370 and
>> its descendants, OpenVMS, and Microsoft Windows NT. ELF apparently
>> was designed in the mid-1990s. I have found a copy of the System V
>> Application Binary Interface from April 2001 that describes symbol
>> preemption in the section on the ELF symbol table.
>>
>> When was symbol preemption when loading shared objects first
>> implemented in Unix? Are there versions of Unix that don't do symbol
>> preemption?
>>
>> -Paul W.
>>
>
3:45 a.m.
On Mon, Jan 13, 2020 at 1:44 PM Paul Winalski <paul.winalski(a)gmail.com>
wrote:
On 1/13/20, Rico Pajarola <rp(a)servium.ch>
wrote:
symbol preemption
yes, but unless my memory is playing tricks, SunOS a.out had this
feature.
Do you mean support for shared libraries, or symbol preemption?
-Paul W.
4:20 a.m.
On Mon, Jan 13, 2020 at 01:45:48PM -0800, Rico Pajarola wrote:
On Mon, Jan 13, 2020 at 1:44 PM Paul Winalski
<paul.winalski(a)gmail.com>
wrote:
My memory of this is it was dns lookups that wanted something like this.
SunOS really wanted the world to love YP but the world wanted Sun to
support DNS. 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.
That's where I first learned of this stuff. Gingell would know if you
want to know for sure.
On 1/13/20, Rico Pajarola <rp(a)servium.ch>
wrote:
symbol preemption
yes, but unless my memory is playing tricks, SunOS a.out had this
feature.
Do you mean support for shared libraries, or symbol preemption?
3:42 a.m.
On 1/13/20, Clem Cole <clemc(a)ccc.com> wrote:
As a result, CMU's MachO was about to become the default
format (OSF and Apple were already using it for that reason), and Unix
International stepped in and convinced AT&T to released the ELF documents
(I was on the UI technical board at that point). I'm not sure how/why OSF
decided to back off, maybe because after ELF became public it got supported
by GCC.
Mach-O was decidedly a step up from a.out in terms of flexibility and
extensibility, but it is inferior to both COFF and ELF, IMO. Mach-O
(at least the Apple OS X implementation) handles global symbols and
relocations in a clumsy and baroque way. Of the three
object/executable formats, ELF is by far the cleanest and most
flexible, and that's possibly why OSF went to it once it became
available.
Microsoft went with COFF, sort-of, in Windows. But PECOFF (Portable
and Extensible Common Object File Format) is different enough from
vanilla COFF that when I implemented support for it in GEM I found to
better to write an entire new module for PECOFF rather than put
conditional code in the existing COFF-handling code. I think this was
another of MS's "embrace and extend" gambits to keep control over
their development environment.
Now my memory is a little hazy... I think OSF/1-386
used MachO originally,
but I've forgotten. Switching the kernel to use ELF was one of the
differences between OSF1 and Tru64 IIRC.
GEM never had to support Mach-O on any of its target platforms. DEC's
Unix on MIPS used COFF. Tru64 used ELF exclusively. I don't know
what Apple used for object files before OS X. IIRC NeXT was based on
the CMU MACH microkernel and hence used Mach-O. OS X is
FreeBSD-based, but it uses Mach-O.
Tru64 has symbol preemption. The Tru64 C/C++ compiler by default
turns off symbol preemption by using PROTECTED visibility for global
symbols, but it does have a --preempt_symbol option. Using that
option can have disastrous effects on optimization.
Was symbol visibility (default/protected/internal) part of the
original ELF spec from the 1990s, or was it added later?
-Paul W.
4:53 a.m.
On Mon, 13 Jan 2020 at 16:43, Paul Winalski <paul.winalski(a)gmail.com> wrote:
OSF/1 on MIPS used ECOFF by default, but at least some versions could also
create and run ELF executables. That was all early to mid 1992, I
believe. I don't have my DECstation up right now to check but I'm sure
that the OSF/1 2.0 beta can do it, and I wouldn't be surprised if the
versions of 1.0 with the v3.0 compiler could also do it. I remember trying
to do ELF shared libraries but I think that support wasn't ready yet, which
is a shame because the ECOFF shared libraries on that platform are not fun
to deal with. Not as bad as SGI's ECOFF shared libraries on IRIX 4
though. I'm not sure if anyone outside of SGI ever bothered to put in the
work required to make one.
Wasn't OSF's original intent to use the OSF/ROSE object format?
-Henry
Now my memory is a little hazy... I think
OSF/1-386 used MachO
originally,
but I've forgotten. Switching the kernel
to use ELF was one of the
differences between OSF1 and Tru64 IIRC.
GEM never had to support Mach-O on any of its target platforms. DEC's
Unix on MIPS used COFF. Tru64 used ELF exclusively. I don't know
what Apple used for object files before OS X. IIRC NeXT was based on
the CMU MACH microkernel and hence used Mach-O. OS X is
FreeBSD-based, but it uses Mach-O.
8:53 a.m.
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.
15 Jan
15 Jan
1:21 a.m.
New subject: two AIX items [was Re: History of symbol preemption
On 1/13/2020 1:58 PM, Paul Winalski wrote:
... LInux, AIX and probably other implementations of
ELF have a
feature in the runtime loader called symbol preemption. When loading
As far as I know, AIX has never used ELF.
On the RT, AIX 1 & 2 used a.out enhanced for basic shared library
support, designed by Larry Loucks with help from ISC, probably John
Levine, if I recall correctly.
Starting with AIX 3, AIX used an extended COFF. See Auslander et al,
"Dynamic Linking and Loading in the AIX System", SA23-2619 RISC
System/6000 Technology p. 151. (I don't have/know of PDF of SA23-2619.)
See, also, https://en.wikipedia.org/wiki/XCOFF.
It seems likely that AIX XCOFF supported symbol preemption, I haven't
tried to determine one way or the other.
AIX on 386 & 370 probably used a.out. Clem probably knows.
An IBM retirees group on Facebook led me to IBM AIX Enhancements and
Modernization at http://www.redbooks.ibm.com/abstracts/sg248453.html,
just available yesterday. I tend to think of AIX as abandoned by IBM in
favor of Linux, but, of course, that isn't really true. I've downloaded
the PDF, but not looked inside.
Charlie
--
voice: +1.512.784.7526 e-mail: sauer(a)technologists.com
fax: +1.512.346.5240 Web: https://technologists.com/sauer/
Facebook/Google/Skype/Twitter: CharlesHSauer
2:31 a.m.
New subject: two AIX items [was Re: History of symbol preemption
On Tue, Jan 14, 2020 at 2:29 PM Charles H Sauer <sauer(a)technologists.com>
wrote:
AIX on 386 & 370 probably used a.out. Clem
probably knows.
I don't remember for sure, but I think that's right. It might have used
COFF, given the time frame but I don't think so since it was originally
targetted for University/Research sites which were a.out oriented.
5:22 a.m.
New subject: two AIX items [was Re: History of symbol preemption
I've got a bunch of paper AIX internals documentation outside the
usual, most interesting from memory is one describing the 4.1 work
where it gained SMP support, pthreads, and a bunch of other things. I
need to get some kind of scanning setup if you are interested.
On Tue, Jan 14, 2020 at 12:29 PM Charles H Sauer
<sauer(a)technologists.com> wrote:
On 1/13/2020 1:58 PM, Paul Winalski wrote:
... LInux, AIX and probably other
implementations of ELF have a
feature in the runtime loader called symbol preemption. When loading
As far as I know, AIX has never used ELF.
On the RT, AIX 1 & 2 used a.out enhanced for basic shared library
support, designed by Larry Loucks with help from ISC, probably John
Levine, if I recall correctly.
Starting with AIX 3, AIX used an extended COFF. See Auslander et al,
"Dynamic Linking and Loading in the AIX System", SA23-2619 RISC
System/6000 Technology p. 151. (I don't have/know of PDF of SA23-2619.)
See, also, https://en.wikipedia.org/wiki/XCOFF.
It seems likely that AIX XCOFF supported symbol preemption, I haven't
tried to determine one way or the other.
AIX on 386 & 370 probably used a.out. Clem probably knows.
An IBM retirees group on Facebook led me to IBM AIX Enhancements and
Modernization at http://www.redbooks.ibm.com/abstracts/sg248453.html,
just available yesterday. I tend to think of AIX as abandoned by IBM in
favor of Linux, but, of course, that isn't really true. I've downloaded
the PDF, but not looked inside.
Charlie
--
voice: +1.512.784.7526 e-mail: sauer(a)technologists.com
fax: +1.512.346.5240 Web: https://technologists.com/sauer/
Facebook/Google/Skype/Twitter: CharlesHSauer
1586
days inactive
1588
days old
14 comments
8 participants
participants (8)
-
Charles H Sauer -
Clem Cole -
Henry Bent -
Kevin Bowling -
Larry McVoy -
Paul Winalski -
Rico Pajarola -
Rob Gingell