Re: mips: disable combreloc for NEWABI

[Jakub Jelinek <jakub at redhat dot com>]

On Sat, Oct 19, 2002 at 06:52:04PM -0300, Alexandre Oliva wrote:
> On Oct 19, 2002, "H. J. Lu" <hjl@lucon.org> wrote:
> 
> > On Sat, Oct 19, 2002 at 06:22:15PM -0300, Alexandre Oliva wrote:
> >> As explained in the comments introduced in the patch below, combreloc
> >> breaks with the n64 ABI, because n64 packs three consecutive
> >> relocations in one.  I've only noticed problems on n64, but n32 also
> >> composes relocations, so I thought I'd leave combreloc disabled for it
> >> too.  I might also have gone ahead and disabled combreloc for all mips
> >> emulations, since the only dynamic relocation is RELATIVE anyway, so
> >> there's no benefit in combining relocations.  Thoughts?  Ok to
> >> install?
> 
> > Follow
> 
> > http://sources.redhat.com/ml/binutils/2002-04/msg00374.html
> 
> Thanks for the pointer.  I agree with Jakub and Alan Modra that we
> still do some sorting, but the only situation in which it might be
> useful is when it groups relative relocations that apply to the same
> page, or the same cache line.  I believe we already get this behavior
> without resorting to sorting :-), since we only have one kind of
> dynamic relocation, namely, RELATIVE.
> 
> Anyway, I'd trade a slight speed up at dynamic load time for the

It is quite noticable, not just slight speed up actually.
If you want to see the numbers, just comment out using l->l_lookup_cache
in glibc's dl-reloc.c, rebuild ld.so and see LD_DEBUG=statistics of some
big C++ binary, like konqueror.
With -z combreloc, you get numbers like:
09256:                   number of relocations: 25737
09256:        number of relocations from cache: 59762
with -z combreloc turned off (or disabled in ld.so so that you don't have
to rebuild all the libraries), the 59762 symbol lookups will have to
go through the expensive _dl_lookup_versioned_symbol resp.
_dl_lookup_symbol (expensive especially when there are 38 shared libs
to look in) and I'm sure it will be a couple tenths of seconds in the apps
startup time even on quite decent hardware.
These are IA-32 numbers, but it doesn't matter much, the same is true
on mips, as this is a generic problem, not arch specific.

	Jakub