Date: Sun, 25 May 2003 15:29:55 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: "Matthew N. Dodd" <mdodd@freebsd.org> Cc: current@freebsd.org Subject: Re: Preliminary ELF prebinding patches available. Message-ID: <20030525222955.GA826@athlon.pn.xcllnt.net> In-Reply-To: <20030525084629.R30007@sasami.jurai.net> References: <20030525061524.H30007@sasami.jurai.net> <xzpaddb8ab8.fsf@flood.ping.uio.no> <20030525084629.R30007@sasami.jurai.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, May 25, 2003 at 09:03:24AM -0400, Matthew N. Dodd wrote: > > Relocatable objects (executables and libraries) contain elements that > require relocation before the are usable. In some cases this relocation > requires symbols to be located and resolved. Resolving these symbols and > performing the lookups imposes some execution overhead. By 'prebinding' > we can do as much of this work beforehand and speed up the actual > relocation process. How does prebinding and lazy binding interact? Lazy binding was introduced to solve the performance issue introduced with dynamic linking. Where lazy binding (or bind on reference) minimizes the runtime overhead by binding only those symbols that are actually used, prebinding seems to go the opposite direction (towards static linking) by avoiding the binding at runtime. > Now lets link test.c with lots of useless libraries: *snip* > normal: 14.003u 4.263s 0:23.14 78.9% 5+174k 0+0io 0pf+0w > prebind: 1.108u 3.231s 0:05.46 79.3% 6+182k 0+0io 0pf+0w > static: 0.000u 0.062s 0:00.15 40.0% 66+229k 0+0io 0pf+0w > > This is just a quick and dirty example mind you; I should really run > things with 10000 iterations and make execloop do its own timing > statistics etc. 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). 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. Some specific comments on the patch: 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". 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. 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. o The prebind cache file format is not sufficiently multi-platform nor does it handle collisions well enough (ie when different executables end up using the same cache file name). Have you thought about updating the executable itself? 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. FYI, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030525222955.GA826>