Preliminary ELF prebinding patches available.

[Matthew N. Dodd]

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 at jurai.net |       2 x '84 Volvo 245DL        | ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |