Re: Preliminary ELF prebinding patches available.

On Sun, May 25, 2003 at 07:34:37PM -0400, Matthew N. Dodd wrote:
> 
> > 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.

I'm not sure I understand what you mean. AFAICT, you only have to
record dependencies if the shared objects are in the initial set
of loadable objects (ie those that must be loaded at initial program
load). It doesn't matter if the program itself loads additional
shared objects.

Also, I don't think dlopen() has any consequences for static linking.
One does not have to provide libraries on the link line if they are
only dlopen()'d.

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

Do you know if the toolchain developers are working on this?

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

The EI_OSABI field in the ELF header (e_ident[]) defines the meaning of
the OS specific extensions (in the same way the e_machine defines the
CPU specific extension).  Since ELFOSABI_NETBSD != ELFOSABI_FREEBSD !=
ELFOSABI_OPENBSD, we need to ensure that the segment type for prebinding
is identical across the OSABIs if we want to share the name. It can be
done, but I would not assume a priori that we'll succeed. I probably
would stick to a FreeBSD specific name until there's complete buy-in.

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

But it can across NFS, right?

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

Please keep that option open. Not only do we have to deal with byte-
order on a single platform, we also have to keep an eye on emulation
layers (ia32 on ia64 and ia32 on amd64).
Decoupling the program from its prebinding information can create all
sorts of nasty (ie unexpected) complexities.

> > 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.  :)

What are the major reasons for not editing the executable in your
opinion?

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel_at_xcllnt.net