Re: Preliminary ELF prebinding patches available.

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_at_xcllnt.net