From owner-freebsd-questions Fri Jun 7 13:24:36 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA18415 for questions-outgoing; Fri, 7 Jun 1996 13:24:36 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA18404 for ; Fri, 7 Jun 1996 13:24:33 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA03901; Fri, 7 Jun 1996 13:18:37 -0700 From: Terry Lambert Message-Id: <199606072018.NAA03901@phaeton.artisoft.com> Subject: Re: Statically linked vs. Dynamically linked programs (fwd) To: humprey@linux1.dlsu.edu.ph (Humprey C. Sy) Date: Fri, 7 Jun 1996 13:18:37 -0700 (MST) Cc: questions@freebsd.org In-Reply-To: from "Humprey C. Sy" at Jun 7, 96 10:42:13 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-questions@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > What are the differences produced from a statically linked program > from dynamically linked program? How do they differ with respect > to being loaded into memory during start of execution? Statically linked: o program code and data in image o library code and data in image o pages loaded from image on reference (program image is swap store) Dynamically linked: o program code and data in image o library data in image o library code in shared library image o shared library image mmap'ed into process address space on startup by modified crt0.o o library code is PIC (Position Independent Code) to allow mapping anywhere for any process. PIC is slower than statically linked code for Intel processors (artifact of DOS legacy, not a problem for most non-Intel chips) o program pages loaded from image on reference (program image is swap store) o library pages loaded from library image(s) on reference (library image is swap store) o library pages likely to be in core because of references by other processes causing high locality of reference. Note1: Because library data is linked into the program image instead of being pulled from the library (this could be fixed by going to seperate COFF or ELF segment ID's for library data mapping), shared library technology does *NOT* qualify under the LGPL relink clause. Vendors should be careful to distribute their linkable object modules to comply with the relink clause, even on Linux. Note2: Shared library calls are indirected through a call table instead of being fixed up on fault reference (like Dll's in windows) in order to allow the call table to remain shared text instead of duplicating pages per process. This is somewhat less efficient, in that an additional 6 cycle jump instruction is required on each reference following fixup. Note3: call table references are resolved at call time instead of being pre-bound at load time. This make initial function reference slower, and is a trade-off for appearance-of-speed on image startup. This was a conscious trade-off. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.