Re: RFC: Caching of lookup results during startup

[Jakub Jelinek <jakub at redhat dot com>]

On Fri, Aug 03, 2001 at 09:57:11AM -0700, Ulrich Drepper wrote:
> Jakub Jelinek <jakub@redhat.com> writes:
> 
> > 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.
> 
> Right.  And I think they put the RELATIVE reloations at the beginning.

Well, first I thought they do (and it makes more sense to do that).
But a quick look at
elfdump -r /lib/libc.so.1 | less
on Solaris 8 shows it is not true:

Relocation: .SUNW_reloc
        type                   offset   addend  section        with respect to
      R_SPARC_GLOB_DAT        0xb8e64        0  .SUNW_reloc    __yday_to_month
      R_SPARC_GLOB_DAT        0xb8f8c        0  .SUNW_reloc    _lib_version
      R_SPARC_GLOB_DAT        0xb8fa8        0  .SUNW_reloc    _siguhandler
      R_SPARC_GLOB_DAT        0xb8e10        0  .SUNW_reloc    __huge_val
      R_SPARC_GLOB_DAT        0xb8f18        0  .SUNW_reloc    _daylight
      R_SPARC_GLOB_DAT        0xb8f6c        0  .SUNW_reloc    _numeric
      R_SPARC_GLOB_DAT        0xb8f44        0  .SUNW_reloc    _timezone
      R_SPARC_GLOB_DAT        0xb8dd0        0  .SUNW_reloc    _getdate_err
      R_SPARC_GLOB_DAT        0xb8f54        0  .SUNW_reloc    optarg
      R_SPARC_32              0xbd948        0  .SUNW_reloc    __wcrtomb_sb
      R_SPARC_32              0xba578        0  .SUNW_reloc    _ex_deregister
      R_SPARC_32              0xbade0        0  .SUNW_reloc    free
      R_SPARC_GLOB_DAT        0xb8f24        0  .SUNW_reloc    free
      R_SPARC_32              0xbd920        0  .SUNW_reloc    __mblen_sb
      R_SPARC_32              0xbdcd0        0  .SUNW_reloc    __wcsftime_std
      R_SPARC_32              0xbd934        0  .SUNW_reloc    __btowc_sb
...
      R_SPARC_32              0xbdad4        0  .SUNW_reloc    __towctrans_std
      R_SPARC_32              0xbde58        0  .SUNW_reloc    __nl_langinfo_std
      R_SPARC_32              0xbdcc8        0  .SUNW_reloc    __strptime_std
      R_SPARC_RELATIVE        0xb81d4  0xbab48  .SUNW_reloc
      R_SPARC_RELATIVE        0xb81fc  0xa46f4  .SUNW_reloc
      R_SPARC_RELATIVE        0xb8200  0xa46fc  .SUNW_reloc
      R_SPARC_RELATIVE        0xb8204  0xa4700  .SUNW_reloc
      R_SPARC_RELATIVE        0xb8208  0xa4708  .SUNW_reloc
      R_SPARC_RELATIVE        0xb820c  0xa4710  .SUNW_reloc
      R_SPARC_RELATIVE        0xb8210  0xa4718  .SUNW_reloc
      R_SPARC_RELATIVE        0xb8214  0xa4724  .SUNW_reloc
...
      R_SPARC_RELATIVE        0xbdf98  0xa5cfc  .SUNW_reloc
      R_SPARC_RELATIVE        0xbdf9c  0xa5d00  .SUNW_reloc
      R_SPARC_RELATIVE        0xbdfa0  0xa5d08  .SUNW_reloc
      R_SPARC_RELATIVE        0xbdfa4  0xa5d10  .SUNW_reloc

Relocation: .rela.plt
        type                   offset   addend  section        with respect to
      R_SPARC_JMP_SLOT        0xb9004        0  .rela.plt      _ld_libc
      R_SPARC_JMP_SLOT        0xb9010        0  .rela.plt      _mutex_lock
...

Now I don't know if it is desired, or if they just screwed up the comparison
function (like they could not get R_SPARC_RELATIVE right neither for sparc32
nor sparc64, but each time with a different bug).

> And more importantly: they define DT_RELACOUNT/DT_RELCOUNT to make it
> possible to speed up the processing (or ignore the relocations).

Sure, I do so too in prelink program and ld -z combreloc would do too.

	Jakub