Hi folks,

For the curious, I'd like to have comparison between RelCache and
Red Hat prelink here:

prelink is a quite complex program and more than a thounsand of lines
long, while RelCache is a lot simpler and a couple hundreds of lines long.

According to its man page, "prelink ... due to fewer relocations ..."
With RelCache, there's only *one* fixup required at load time for each
process (__progname). No relocations required for shared objects linked
at startup time. (Of course, it's technically impossible to prebind
objects which are dynamically loaded while process is running)

prelink has to maintain conflicts list to keep track of symbols of the
same name in different objects, but RelCached ld.elf_so doesn't. 

With execloop test, prelink reduced loading time by 35%. With the same
test, the new RelCache reduced 37% on my machine. The number could be
even larger if RelCache was put in executable. 

prelink is more difficult to port to other platform. Since RelCache doesn't
depend on any of architecture specific features, it is easily portable.

An advantage of prelink over RelCache is that it needs less disk
space (not memory). Currently I'm investigating to reduce RelCache size.

And comparions with other implementations:

Some prebinding implementations modify shared objects to set the
preferred load address. As a result, any newly added shared objects
may require prebinding against the whole system. Otherwise, two
objects could overlap in memory space, and thereby cause them to be
relocated. With RelCache, you don't have to maintain the list of load
addresses for shared objects in the system (less burden to system
admin).

Some OS'es perform prebinding at install time, so it often takes 
30 minutes or more to finish. With RelCache, you can ship prebound
binaries in the base OS distribution. No waste of time (for user).

Jun-Young

-- 
Bang Jun-Young <junyoung@netbsd.org>