From owner-freebsd-current@FreeBSD.ORG Sun May 25 16:34:39 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 82DBA37B40D for ; Sun, 25 May 2003 16:34:39 -0700 (PDT) Received: from sasami.jurai.net (sasami.jurai.net [66.92.160.223]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBF7D43F3F for ; Sun, 25 May 2003 16:34:38 -0700 (PDT) (envelope-from mdodd@FreeBSD.ORG) Received: from sasami.jurai.net (sasami.jurai.net [66.92.160.223]) by sasami.jurai.net (8.12.9/8.12.9) with ESMTP id h4PNYb3q002471; Sun, 25 May 2003 19:34:37 -0400 (EDT) (envelope-from mdodd@FreeBSD.ORG) Date: Sun, 25 May 2003 19:34:37 -0400 (EDT) From: "Matthew N. Dodd" X-X-Sender: winter@sasami.jurai.net To: Marcel Moolenaar In-Reply-To: <20030525222955.GA826@athlon.pn.xcllnt.net> Message-ID: <20030525190744.A86964@sasami.jurai.net> References: <20030525061524.H30007@sasami.jurai.net> <20030525222955.GA826@athlon.pn.xcllnt.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@FreeBSD.ORG Subject: Re: Preliminary ELF prebinding patches available. 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: Sun, 25 May 2003 23:34:40 -0000 On Sun, 25 May 2003, Marcel Moolenaar wrote: > How does prebinding and lazy binding interact? If you look at rtld.c:relocate_objects() you'll see that the bind_now conditional controls the behavior that would affect lazy binding. The rtld.c:_rtld() entry function calls relocate_objects() to setup the initial objects; regardless of setting of the bind_now variable the work in relocate_objects() -must- be done. I have not yet performed testing to determine how much time the 'bind_now' behavior of prebinding takes. > Interesting. However, it seems to me that prebinding is solving a > problem it should not be solving. I would expect that the toolchain > sanitizes the dependency list. Put differently, if I add a library to a > link but none of the exported symbols are actually being referenced, > then there's no dependency and the final shared object should not have > that library recorded at all. The runtime overhead between a minimal > link and a bloated link would then be minimal (there's always the chance > of false positives). This doesn't seem to be the case, or if it is our rtld isn't taking advantage of any toolchain hints. All relocations in a shared libraries must be handled on the off chance that the program will dlopen() a shared object. > To explicitly state my standing on prebinding: I'm mostly un- convinced > that it's something we need at this time. Patching the toolchain is > considered a sin by me. Also, the footnote that it "only works for i386 > for now" is getting annoying and to me only means that the testing > results are too colored or biased to be useful. I'm not happy with having to patch the toolchain either. With respect to your complaints that the code is x86 centric; my plans are to continue working on the code and split it out into MI/MD bits. > o An OS specific segment type/name is expected to be prefixed by > the os name to avoid collition. Thus: (type)PT_FREEBSD_BUILDID > and (name)".freebsd.buildid". Maybe PT_BSD_BUILDID since it should be fairly easy to get this code running on the other BSD systems. > o The use of time and some random key is too adhoc and does not > really provide the uniqueness one wants. Given that UUIDs have > showed up in a lot of places not originally intended for UUIDs > to show up, one might as well use UUIDs here. Make sure you > nail down the byte order if you want to use UUIDs. I was more concerned with simplicity; the method I use solves the problem with minimal effort and complexity. The combination of time() + random() + filename will not collide on a single box. > o Of course the i386 specifics in the non-i386 specific file > libexec/rtld-elf/prebind.c is something that clearly needs to > be fixed. Of course. > o The prebind cache file format is not sufficiently multi-platform I'll be adding a platform identifier to the file header. All I'm concerned with is being able to reject a file if its not for the current platform. I have no expectation of cross-generating prebinding files. > nor does it handle collisions well enough (ie when different > executables end up using the same cache file name). This is actually handled. I'll likely change the format of the filenames as well. > Have you thought about updating the executable itself? Of course. I eliminated all the wrong/impossible methods of implementing prebinding. Having the prebinding cache file added as an ELF section was one of the first things I tried. :) > o The prebinding stuff will probably not work as-is ia64 (this is > of course if we ignore the i386 specifics for a moment and look > at the framework). If my cursory glance over the patch isn't > deceiving me, we don't have the right information yet to deal > with the function descriptors, which means that some of the > runtime overhead is not properly resolved, and thus devaluating > the usefulness of prebinding. My read of the ia64 code didn't reveal any major difficulties. Its possible that I'm missing something though. I'm most concerned about the sparc64 code. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever |