Re: Prebinding for DragonFly/FreeBSD-4

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:> Prebinding on a per executable basis rather than a per "object" (ELF
:> executable or library) means that when you go to prebind KDE (for
:> example) you run /var out of diskspace :/
:
:Yes, that might be true. How about this approach:
:(doesn't cope with cyclic ``needs'' yet)
:
:- assign every .so a base address so that no collisions happen for every
:  binary considered
:
:Then, for every binary:
:- start with resolving the last object (often libc), as if only this
:  object was loaded
:- proceed to the next object (might be another .so or the binary)
:- there again, resolve stuff. if this changes resolved data in
:  objects resolved before (global references...), save this data too,
:  like deltas to the data of the object before.
:- loop
:
:This means: Every object has the data assigned which it ultimatively
:requests. If globals etc exists they will overridden by the next object
:which requested previous object.
:
:On load, just run the same way. First, load data of the last object
:(i.e. libc), then running the object list back to the binary, load data.
:Globals that get resolved another way than without object X will be
:overwriten by the patchup data for object X.
:
:Uhg, I hope I made myself (at least partly) clear enough to follow.
:
:cheers
:  simon

    Hmm.  There could be a problem with that.  If the ordering of the
    libraries change the checksums will not (I think), but the patchups
    will now be applied in the wrong order.

    Maybe the prebinding should be explicit... that is, you run a program
    to prebind a binary and it stores the prebinding in the same directory
    as the binary.  Just running the binary would not in itself *create*
    a prebinding file, but it would check to see if one exists and is valid.

						-Matt