Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!necntc!ci-dandelion!ulowell!apollo!labo From: labo@apollo.uucp (Dale Labossiere) Newsgroups: comp.arch,comp.unix.wizards,comp.os.misc Subject: Re: Big Programs Hurt Performance Message-ID: <376e654f.1201@apollo.uucp> Date: Tue, 22-Sep-87 11:13:00 EDT Article-I.D.: apollo.376e654f.1201 Posted: Tue Sep 22 11:13:00 1987 Date-Received: Thu, 24-Sep-87 05:46:48 EDT References: <1665@ncr-sd.SanDiego.NCR.COM) <8579@utzoo.UUCP) <6886@eddie.MIT.EDU) <2501@xanth.UUCP> <2067@sfsup.UUCP> Reply-To: labo@apollo.UUCP (Dale Labossiere) Organization: Apollo Computer, Chelmsford, MA Lines: 46 Xref: mnetor comp.arch:2301 comp.unix.wizards:4411 comp.os.misc:211 In article <2067@sfsup.UUCP> shap@sfsup.UUCP (J.S.Shapiro) writes: >In article <2501@xanth.UUCP>, kyle@xanth.UUCP (Kyle Jones) writes: >> In <14888@topaz.rutgers.edu>, hedrick@topaz.rutgers.edu (Charles Hedrick) sez: >> >> Please explain more about shared libraries. > > ... A portion of the address space is >reserved in advance by *everyone* for each shared library (that is, the >shared library has a permanent reserved location in the virtual address >space). > > ... > >It is worth noting that a better scheme, though much more difficult, is to >generate "position independent code" so that you do not have to reserve the >address of the library. You can then use exactly the same tricks, but >generate your function calls via a jump table in the executable's data >space. When you 'attach' the shared library, you copy the table out of the >library into your own, adjusting the entries so that the function addresses >are correct. This scheme has the advantage that you don't have to reserve >large chunks of your address space. Unfortunately, position independent >code is quite difficult to do, which is why current UNIX compilers (to my >knowledge) don't do it. This scheme is referred to as "dynamic loading." > > ... >Jonathan Shapiro This "dynamic loading" scheme is in fact what Apollo systems use. The compilers generate position independent code, and the libraries can be mapped anywhere in the process's address space. Rather than have a monolithic jump table for a shared library, shared libraries "register" their global addresses in a "Known Global Table" (KGT). Programs which invoke shared library functions do so via an indirect address linkage variable in their data space (the slight difference being that there are only linkage variables for those shared functions that are invoked, not a complete table for all of the libraries functions). Object files are tagged and when executed, the system loader (not UNIX ld(1)) resolves the undefined global's addresses using the KGT and patches up the program's linkage variables. -- Dale LaBossiere (617) 256-6600 x4292 Apollo Computer 330 Billerica Rd. UUCP: {mit-erl,yale,uw-beaver,decvax}!apollo!labo Chelmsford Ma. 01824 ARPA: apollo!labo@eddie.mit.edu