RFC: Caching of lookup results during startup

[Jakub Jelinek]

On Wed, Aug 01, 2001 at 01:18:46AM -0700, Ulrich Drepper wrote:
> Andreas Jaeger <aj@suse.de> writes:
> 
> > I haven't seen binutils patches for this yet and looking at his
> > description he seems to do the reordering in his prelinker.
> 
> For now this is true I assume.

Yes, for now I do the .rel{,a}.* except .rel{,a}.plt merging and reordering
in the prelinker. It can be done in ld too though.
I'll try to cook up a patch soon.
Sun linker uses -z combreloc to request this, maybe this should be default
GNU ld behaviour though and have -z nocombreloc to disable it.

BTW: I'm not doing a simple qsort to reorder the relocs, I do 2 qsorts and
some magic in between, so that:
a) R_*_RELATIVE symbols come last, sorted by increasing r_offset
b) the rest of relocs are sorted by r_offset as long as they have different
   ELFW(R_SYM). If they have the same R_SYM, they are together, with
   R_*_COPY symbols coming last, R_*_JMP_SLOT before that and other relocs
   first, in each subcategory sorted by increasing r_offset

This way, the locality is IMHO better than if they would be simply sorted by
ELFW(R_SYM), if there are no symbols with the same R_SYM, aside from
R_*_RELATIVE the order is the same as ld sorted them so far (and
R_*_RELATIVE relocs are expected not to be done for relocated libraries and
grouping them together means they can be cheaply skipped all at once).

	Jakub