From owner-freebsd-current@FreeBSD.ORG Thu Nov 27 23:59:20 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B67B16A4CE for ; Thu, 27 Nov 2003 23:59:20 -0800 (PST) Received: from server.vk2pj.dyndns.org (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2938A43F93 for ; Thu, 27 Nov 2003 23:59:18 -0800 (PST) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1])hAS7xBJD023585 for ; Fri, 28 Nov 2003 18:59:11 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.12.9p1/8.12.9/Submit) id hAS7xBgZ023584 for freebsd-current@freebsd.org; Fri, 28 Nov 2003 18:59:11 +1100 (EST) (envelope-from peter) Date: Fri, 28 Nov 2003 18:59:11 +1100 From: Peter Jeremy To: freebsd-current@freebsd.org Message-ID: <20031128075911.GB23322@server.vk2pj.dyndns.org> References: <3FC60848.5030908@catpa.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Subject: Re: Apples linking X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2003 07:59:20 -0000 On Thu, Nov 27, 2003 at 11:24:23AM -0500, Robert Watson wrote: [Darwin pre-binding] >presumably applies to other processor architectures. The one thing that >turns me off to this scheme is that I'd like it if we could find a way to >represent this using solely existing BSD/UNIX kernel primitives (mmap, et >al) and userspace, rather than adding special-purpose system calls that >complicated various code paths, and that aren't portable. Compaq/HP Tru64 supports link-time pre-binding, called "Quickstart". To use it, shared libraries are linked to load at mutually exclusive addresses and applications are linked assuming the preferred .so load addresses. At run-time, the rtld verifies that it can map every shared library at its preferred address and that each shared library is the same one the application was linked against (using checksums in the COFF headers). If all this is true, all the relocations are correct and execution starts immediately. If any checks fail, rtld falls back to the traditional check-every-symbol-and-relocation approach. The benefit is very fast start times - not much more overhead than starting a static executable. The disadvantages are: - if any library changes, all dependent applications must be relinked to maintain the fast start. In some cases a utility can be used to re-validate the checksums in the application if the library hasn't grown and is at the same address. - circular shared library dependencies aren't allowed - a writable common list of .so load addresses is needed at .so link time. - having reserved address space for each shared library results in a fragmented process address space and may impact on the space available to the application. For more details see the following links http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51B_HTML/ARH9VDTE/SHLBCHPX.HTM#using-quickstart http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51B_HTML/SUPPDOCS/OBJSPEC/NV140XXX.HTM#nav14-54 I don't believe it is feasible to do much about the i386 PIC overheads other than moving to a saner processor architecture. What other techniques are used to improve shared library startup times in other operating systems? Peter