On Wed, Dec 04, 2002 at 12:38:49PM +0100, Martin Husemann wrote:
> On Wed, Dec 04, 2002 at 08:26:46PM +0900, Bang Jun-Young wrote:
> 
> > >  - for N programs loading the shared libc, you get N prebound
> > >    cache files?
> > 
> > Right. (Per shared object cache breaks the ELF semantics) 
> 
> Can you explain this in a bit more detail for ELF-unaware people like me?

If you examine ELF executable and its required shared libraries with
readelf or objdump, you will notice that symbols of the same name are
found in more than one file. These include __ps_strings, __sF, optarg,
optind, etc. So, when you look up a symbol of those, how do you know
which is the right one? It's called "conflict" and should be resolved
by the dynamic linker at relocation time.

In the "V1" of prebind, I used a hack to resolve conflicts, as follows:

/*
 * These symbols are marked unresolvable.
 */

char *marked[] = {
	"__ps_strings",
	"__sF",
	"optarg",
	"optind"
};

This way I could avoid conflicts between well known symbols, but even 
more serious problem arose: what if some new symbol caused "conflict"?
Whenever such symbol is found, I would have to add it to the list. And
that inevitably leads me to compile and install ld.elf_so over and over
again. That's why I abandoned the previous approach completely.

> 
> Having this much cache files around sucks badly, btw.

In upcoming implementation, cache will be embedded into executable.

> 
> Martin
> P.S.: if ELF breaks all this, can't we switch to a sane object format?
> (ducks)

;-) With RelCache, there will be no need to invent a new format.

Jun-Young

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