Date: Fri, 7 Jun 1996 13:18:37 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: humprey@linux1.dlsu.edu.ph (Humprey C. Sy) Cc: questions@freebsd.org Subject: Re: Statically linked vs. Dynamically linked programs (fwd) Message-ID: <199606072018.NAA03901@phaeton.artisoft.com> In-Reply-To: <Pine.LNX.3.91.960607224136.3823F-100000@ccslinux.dlsu.edu.ph> from "Humprey C. Sy" at Jun 7, 96 10:42:13 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606072018.NAA03901>