Date: Sun, 25 May 2003 19:34:37 -0400 (EDT) From: "Matthew N. Dodd" <mdodd@FreeBSD.ORG> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: current@FreeBSD.ORG Subject: Re: Preliminary ELF prebinding patches available. Message-ID: <20030525190744.A86964@sasami.jurai.net> In-Reply-To: <20030525222955.GA826@athlon.pn.xcllnt.net> References: <20030525061524.H30007@sasami.jurai.net> <xzpaddb8ab8.fsf@flood.ping.uio.no> <20030525222955.GA826@athlon.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030525190744.A86964>