From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 14 10:27:14 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5A9E16A4BF for ; Sun, 14 Sep 2003 10:27:14 -0700 (PDT) Received: from mail.fs.ei.tum.de (stella.fs.ei.tum.de [129.187.54.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C93C43F3F for ; Sun, 14 Sep 2003 10:27:11 -0700 (PDT) (envelope-from corecode@fs.ei.tum.de) Received: from localhost (localhost [127.0.0.1]) by localhost.fs.ei.tum.de (Postfix) with ESMTP id BD96F30003; Sun, 14 Sep 2003 19:27:04 +0200 (CEST) Received: from hydra.fs.ei.tum.de (hydra.fs.ei.tum.de [192.168.113.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by mail.fs.ei.tum.de (Postfix) with ESMTP id 0148930002; Sun, 14 Sep 2003 19:27:02 +0200 (CEST) Date: Sun, 14 Sep 2003 19:26:55 +0200 From: Simon 'corecode' Schubert To: "Matthew N. Dodd" Message-Id: <20030914192655.51deb3a4.corecode@fs.ei.tum.de> In-Reply-To: <20030913012449.Y27896@sasami.jurai.net> References: <20030913045444.407b1cd6.corecode@fs.ei.tum.de> <20030913012449.Y27896@sasami.jurai.net> X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.s2C6?ZlJKlwc.g" X-Virus-Scanned: by AMaViS 0.3.12 cc: bsd@ibotty.net cc: hackers@freebsd.org cc: kernel@lists.dragonflybsd.org Subject: Re: Prebinding for DragonFly/FreeBSD-4 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2003 17:27:14 -0000 --=.s2C6?ZlJKlwc.g Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Lately Matthew N. Dodd told: > Prebinding on a per executable basis rather than a per "object" (ELF > executable or library) means that when you go to prebind KDE (for > example) you run /var out of diskspace :/ Yes, that might be true. How about this approach: (doesn't cope with cyclic ``needs'' yet) - assign every .so a base address so that no collisions happen for every binary considered Then, for every binary: - start with resolving the last object (often libc), as if only this object was loaded - proceed to the next object (might be another .so or the binary) - there again, resolve stuff. if this changes resolved data in objects resolved before (global references...), save this data too, like deltas to the data of the object before. - loop This means: Every object has the data assigned which it ultimatively requests. If globals etc exists they will overridden by the next object which requested previous object. On load, just run the same way. First, load data of the last object (i.e. libc), then running the object list back to the binary, load data. Globals that get resolved another way than without object X will be overwriten by the patchup data for object X. Uhg, I hope I made myself (at least partly) clear enough to follow. cheers simon -- /"\ http://corecode.ath.cx/#donate \ / \ ASCII Ribbon Campaign / \ Against HTML Mail and News --=.s2C6?ZlJKlwc.g Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/ZKTmr5S+dk6z85oRAs+ZAJ4nDXU1IABA5Sstg/E/TcUrfwofZQCaAwLM BSK681FZblROSdSQO1aCplk= =msZJ -----END PGP SIGNATURE----- --=.s2C6?ZlJKlwc.g--