[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

combreloc clarifications

    I just wanted to clarify a couple issues about the combreloc.
It has been brought to my attention that not every build machine is
up to binutils > or later. In that case, you should
complain and ask that the build machine become current. The second
point is that although for combreloc to be operatoional glibc needs to be
rebuilt against the -z combreloc enabled binutils, this is not essential
for enabling all the other programs. You could build every other program
besides glibc first and leave glibc for last. It will all work the same.
When glibc is configured it looks for combreloc support in binutils and
if present enables its own combreloc support.  That is why glibc must be 
rebuilt against a binutils > for combreloc to actually 
become functional.
    One other note...if anyone is curious to reproduce my measurements
from LD_DEBUG=statistics you can do so with the following patch to
glibc 2.2.4-4...

diff -uNr glibc-2.2.4/elf/dl-reloc.c glibc-2.2.4.new/elf/dl-reloc.c
--- glibc-2.2.4/elf/dl-reloc.c	Wed Oct 31 09:25:02 2001
+++ glibc-2.2.4.new/elf/dl-reloc.c	Wed Oct 31 09:27:19 2001
@@ -97,7 +97,7 @@
      : l)
 #define RESOLVE(ref, version, r_type) \
     (ELFW(ST_BIND) ((*ref)->st_info) != STB_LOCAL			      \
-     ? ((__builtin_expect ((*ref) == l->l_lookup_cache.sym, 0)		      \
+     ? ((0 && __builtin_expect ((*ref) == l->l_lookup_cache.sym, 0)		
 	 && elf_machine_type_class (r_type) == l->l_lookup_cache.type_class)  \
 	? (++_dl_num_cache_relocations,					      \
 	   (*ref) = l->l_lookup_cache.ret,				      \

This will disable combreloc in glibc so you can run programs with
LD_DEBUG=statistics with that glibc and one a normal glibc to see
how much of an improvement any particular program gets.
                         Jack Howarth

Reply to: