From owner-freebsd-questions Fri Jun 7 13:43:33 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA19939 for questions-outgoing; Fri, 7 Jun 1996 13:43:33 -0700 (PDT) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA19907 for ; Fri, 7 Jun 1996 13:43:15 -0700 (PDT) Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA09707; Fri, 7 Jun 1996 16:41:21 -0400 Date: Fri, 7 Jun 1996 16:41:21 -0400 From: Garrett Wollman Message-Id: <9606072041.AA09707@halloran-eldar.lcs.mit.edu> To: Terry Lambert Cc: questions@freebsd.org Subject: Re: Statically linked vs. Dynamically linked programs (fwd) In-Reply-To: <199606072018.NAA03901@phaeton.artisoft.com> References: <199606072018.NAA03901@phaeton.artisoft.com> Sender: owner-questions@freebsd.org X-Loop: FreeBSD.org Precedence: bulk < said: [about executables linked -shared] > o library data in image I believe this to be incorrect. This is a correct description of the way Sun's libraries work, but my understanding was that we avoid this. > o shared library image mmap'ed into process address > space on startup by modified crt0.o No. /usr/libexec/ld.so loader image mmap'ed into process address space on startup by crt0.o. Shared library images are mmaped by ld.so. > 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) Not an artifact of DOS legacy, but rather a result of the paucity of registers on 8086-family CPUs. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant