Re: -z combreloc

[Jakub Jelinek <jakub@redhat.com>]

On Sat, Oct 13, 2001 at 01:46:12PM -0400, Jack Howarth wrote:
> Hello,
>    Debian is preparing to enable -z combreloc
> in their binutils 2.11.92.0.5 packages. On Debian
> ppc sid the -z combreloc enabled binutils builds
> fine and passes all of make check without problems.
> This is enabling -z combreloc with the simple patch...

We are using it in Red Hat binutils too for some time already, but only
apply it on elf platforms which are known to work with it.
Particularly, only ELF backends for which DT_TEXTREL handling has been
updated can have this on, which I think is not all yet (plus on mips the
separate .rel.dyn handling should be killed and use the common code).

> 2001-09-28  Ulrich Drepper  <drepper@redhat.com>
> 
> 	* elf/elf.h: Define SHF_GROUP and SHF_TLS.
> 
> ...are there any changes in glibc cvs since then with
> essential fixes for -z combreloc to work properly on
> any arches?

Why in glibc? SHF_GROUP is for ET_REL objects only as ELF standard sais, so
glibc has nothing to do with SHF_GROUP.
With -z combreloc, there are no changes needed in glibc, everything will
work as it used to, just when glibc knows about DT_REL*COUNT and has the one
entry lookup cache, it will make program startup faster.
Current glibc 2.2.4 has all this in.

> 3) Lastly, if one builds binaries on a machine with
> a binutils installed with -z combreloc enabled and
> transfers this to a machine with an older binutils
> with -z combreloc disabled...should we expect any
> backward compatibility issues in running these? 

Nope. As dynamic linker doesn't care about section table, the only change
visible to ld.so with -z combreloc and -z nocombreloc is that relocations
are sorted differently. But ld.so doesn't care about their ordering (well,
with -z nocombreloc e.g. .rel*.got is completely unsorted).

	Jakub