[comp.os.misc] shared libraries and dynamic relocation

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