andrew@frip.gwd.tek.com (Andrew Klossner) (09/13/88)
[]
"It also means it's easier to make it more powerful;
the SunOS shared libraries are not tied to specific
locations, and relocation is done when the library is
mapped in."
"What are the performance trade-offs here? All of Sun's
hardware may support position independent code, but I wonder
what the expense would be of actually relocating the library
code on each and every exec() on a processor where all branches
are absolutely addressed."
Note that AT&T has announced that, with system V release 4, they will
also do dynamic loading on exec to support shared system calls. They
will also trash the COFF format in favor of yet another object file
format, ELF.
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(andrew%tekecs.tek.com@relay.cs.net) [ARPA]sjs@jcricket.ctt.bellcore.com (Stan Switzer) (09/13/88)
andrew@frip.gwd.tek.com (Andrew Klossner) writes: > Note that AT&T has announced that, with system V release 4, they will > also do dynamic loading on exec to support shared system calls. They > will also trash the COFF format in favor of yet another object file > format, ELF. > Can someone summarize this new ELF format, with advantages and disadvantages listed. I hope they took C++ needs into consideration (especially debugging information). Is there provision for sharing of string literals (or other literals) across object module boundaries? Is there a specific storage class for "consts" separate from text (on some architectures this is important)? Stan Switzer sjs@ctt.bellcore.com