Re: -z combreloc

Re: -z combreloc

[Jack Howarth]

Andrew,
    I'm rather amused that you are giving debian such grief
for daring to use the actual version number coupled with
a packaging version number, yet I haven't hear a peep out
of you about RedHat doing the same. I would remind you
that RedHat srpms for binutils, while they are based on
the hjl tarballs, contain patches from maintainers who
are not hjl. Also RedHat isn't the only rpm based system.
So one could just as easily make the argument that RedHat
should never release anything without using 2.11.92.rh.5
or such...

from  "/pub/redhat/linux/7.1/en/os/i386/SRPMS"
-rw-r--r--    4 0        0         7064578 Apr 08  2001 binutils-2.10.91.0.2-3.src.rpm

                     Jack
------------------------------------------------------------------------------
Jack W. Howarth, Ph.D.                                    231 Albert Sabin Way
NMR Facility Director                              Cincinnati, Ohio 45267-0524
Dept. of Molecular Genetics                              phone: (513) 558-4420
Univ. of Cincinnati College of Medicine                    fax: (513) 558-8474

Re: -z combreloc

[Andrew Cagney]

cagney@toribio$ /usr/bin/gdb --version
GNU gdb 5.0rh-5 Red Hat Linux 7.1

Re: -z combreloc

[Christopher C. Chimelis]

On Sat, 13 Oct 2001, Andrew Cagney wrote:

> cagney@toribio$ /usr/bin/gdb --version
> GNU gdb 5.0rh-5 Red Hat Linux 7.1

This is easily solved.  I can patch it thus for Debian.  In fact, I will
in the next upload.  Thanks for the suggestion :-)

Instead of:
~ > ld -V
GNU ld version 2.11.92.0.5 20011005
  Supported emulations:
   elf64alpha
   alpha

Would this be an improvement at least?
~ > ld -V
GNU ld version 2.11.92.0.5 20011005 Debian GNU/Linux
  Supported emulations:
   elf64alpha
   alpha

Re: -z combreloc

[Andrew Cagney]

> Andrew,
>     I'm rather amused that you are giving debian such grief
> for daring to use the actual version number coupled with
> a packaging version number, yet I haven't hear a peep out
> of you about RedHat doing the same. I would remind you
> that RedHat srpms for binutils, while they are based on
> the hjl tarballs, contain patches from maintainers who
> are not hjl. Also RedHat isn't the only rpm based system.
> So one could just as easily make the argument that RedHat
> should never release anything without using 2.11.92.rh.5
> or such...
> 
> from  "/pub/redhat/linux/7.1/en/os/i386/SRPMS"
> -rw-r--r--    4 0        0         7064578 Apr 08  2001 binutils-2.10.91.0.2-3.src.rpm

To be clear, I'm not trying to give you grief.  I'm raising a flag 
saying ``hey this could be a problem''.  Given the above, it looks like 
there really is an issue.

You'll notice that I did manage to get Red Hat to change their GDB 
version number.  Hopefully Debian did the same with their GDB distribution.

enjoy,
Andrew

Re: -z combreloc

[Daniel Jacobowitz]

On Sat, Oct 13, 2001 at 11:12:32PM -0400, Andrew Cagney wrote:
> >Andrew,
> >    I'm rather amused that you are giving debian such grief
> >for daring to use the actual version number coupled with
> >a packaging version number, yet I haven't hear a peep out
> >of you about RedHat doing the same. I would remind you
> >that RedHat srpms for binutils, while they are based on
> >the hjl tarballs, contain patches from maintainers who
> >are not hjl. Also RedHat isn't the only rpm based system.
> >So one could just as easily make the argument that RedHat
> >should never release anything without using 2.11.92.rh.5
> >or such...
> >
> >from  "/pub/redhat/linux/7.1/en/os/i386/SRPMS"
> >-rw-r--r--    4 0        0         7064578 Apr 08  2001 
> >binutils-2.10.91.0.2-3.src.rpm
> 
> To be clear, I'm not trying to give you grief.  I'm raising a flag 
> saying ``hey this could be a problem''.  Given the above, it looks like 
> there really is an issue.
> 
> You'll notice that I did manage to get Red Hat to change their GDB 
> version number.  Hopefully Debian did the same with their GDB distribution.

No, we don't, but probably I should fix that :)  The only patch I
actually apply beyond a CVS tarball was just committed to CVS, though,
so I really don't see a reason to.  Debian is fairly good about making
it clear where bug reports should go.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: -z combreloc

[Andrew Cagney]

> You'll notice that I did manage to get Red Hat to change their GDB 
>> version number.  Hopefully Debian did the same with their GDB distribution.
> 
> 
> No, we don't, but probably I should fix that  [:)] The only patch I
> actually apply beyond a CVS tarball was just committed to CVS, though,
> so I really don't see a reason to.  Debian is fairly good about making
> it clear where bug reports should go.

If it is a pure GDB distribution then there is probably no benefit in 
changing it.  It is nice to see that things are slowly converging.

enjoy,
Andrew

Re: -z combreloc

[Andrew Cagney]

> Also, why should I diverge from the numbering scheme when no other vendors
> are?  There are sub-versioning done on a Debian level anyway (ie. the
> latest package in the archive is 2.11.92.0.5-2).

Hmm, at least you're subversioning.

Why diverge from numbers?  It helps clarify the origins of a non FSF 
release of a tool.  Someone files a bug with ``2.11.92.hj.5'' then 
everyone knows that it is a H.J. branch.  On the other hand, 2.11.92.0.5 
could either be H.J. the FSF, or even some other party.

your choice I guess,
Andrew

Re: -z combreloc

[Christopher C. Chimelis]

On Sat, 13 Oct 2001, Andrew Cagney wrote:

> I'm just suggesting a rename of the version number to something that 
> contains more than digits.  To pull something out of thin air - 
> 2.11.2.debian.5.  That way there isn't any confusion between your 
> releases and the official binutils releases.
> 
> As best as I can tell, both you and H.J. have now both adopted an 
> identical branch versioning schema.  Arrrg!

All of the Debian packages are based upon H.J.'s versions.  In fact, the
tarball within the .orig.tar.gz is straight from his ftp area.  Any
patches applied are contained the the debian/patches dir in the source
package.

Also, why should I diverge from the numbering scheme when no other vendors
are?  There are sub-versioning done on a Debian level anyway (ie. the
latest package in the archive is 2.11.92.0.5-2).

C

Re: -z combreloc

[Andrew Cagney]

I'm just suggesting a rename of the version number to something that 
contains more than digits.  To pull something out of thin air - 
2.11.2.debian.5.  That way there isn't any confusion between your 
releases and the official binutils releases.

As best as I can tell, both you and H.J. have now both adopted an 
identical branch versioning schema.  Arrrg!

enjoy,
Andrew

Re: -z combreloc

[Jakub Jelinek]

On Sat, Oct 13, 2001 at 04:14:16PM -0400, Jack Howarth wrote:
> howarth@bogus:~/debian6/zip-2.30$ LD_DEBUG=statistics ./zip 
> 08344:                   number of relocations: 256
> 08344:        number of relocations from cache: 99

This means ld.so does 355 symbol lookups, 99 of them are served from lookup
cache, the rest are looked up.

> ...after prelinking this binary I got...
> 
> howarth@bogus:~/debian6/zip-2.30$ LD_DEBUG=statistics ./zip
> 08355:                   number of relocations: 0
> 08355:        number of relocations from cache: 16

This means prelinking could be used, so no symbol lookups, just 16 conflicts
were applied (conflicts are always Rela relocs against symidx 0, so no
lookup).

> prelink: /lib/libncurses.so.5.2: Not enough room to add .dynamic entry

This means libncurses.so.5.2 was not rebuilt with recent binutils
(particularly there are no spare .dynamic section entries which prelink
needs for its work).

> under a newer binutils but all libs linked in have to
> be as well. Is this true?

Sure.

>     Lastly back to -z combreloc...is there a good way to
> benchmark any speed up gained by recompiling with that 
> option enabled in binutils? Jakub seems to have different
> output from LD_DEBUG=statistics than we do (he can get

The difference is that glibc powerpc port doesn't support HP_TIMING_*.
From what I understand, there is mftb instruction on ppc which sets a
register to current timer value, but it is not supported on some earlier PPC
CPUs and it looks like it is 32-bit only (right?). In this case, someone
would need to hack up some way how to configure glibc which would not
support these older PPC CPUs and, assuming it is really 32-bit only and thus
overflows quickly, look at Alpha HP_TIMING_* which is limited for short time
periods too.

	Jakub

Re: -z combreloc

[Jakub Jelinek]

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

Re: -z combreloc

[Jack Howarth]

Andrew,
    I'm not sure I understand what you mean. I didn't
mean to imply that change should go into the cvs.
I mean to alert everyone that Debian was taking the
leap in sid to using -z combreloc.
    A few other questions for anyone who would care
to answer...

So far I have been able to test a simple case with prelink
(it always has passed its own make check). I rebuilt zip
with the new binutils 2.11.92.0.5 and found that I got...

howarth@bogus:~/debian6/zip-2.30$ LD_DEBUG=statistics ./zip 
08344:                   number of relocations: 256
08344:        number of relocations from cache: 99

...after prelinking this binary I got...

howarth@bogus:~/debian6/zip-2.30$ LD_DEBUG=statistics ./zip
08355:                   number of relocations: 0
08355:        number of relocations from cache: 16

...and it seems to be running okay. I also tried doing the
same with bash but it complained...

prelink ./bash
prelink: /lib/libncurses.so.5.2: Not enough room to add .dynamic entry

I take this to imply that as far as prelinking goes that
not only does the program in question have to be rebuilt
under a newer binutils but all libs linked in have to
be as well. Is this true?
    Lastly back to -z combreloc...is there a good way to
benchmark any speed up gained by recompiling with that 
option enabled in binutils? Jakub seems to have different
output from LD_DEBUG=statistics than we do (he can get
....

LD_DEBUG=statistics kmail
14751:
14751:  runtime linker statistics:
14751:    total startup time in dynamic loader: 226875015 clock cycles
14751:              time needed for relocation: 223635459 clock cycles (98.5%)
14751:                   number of relocations: 24432
14751:        number of relocations from cache: 45710
14751:             time needed to load objects: 2969083 clock cycles (1.3%)


...whereas all we seem to get in debian is a simple listing of
relocations. Thanks in advance for any information.
                      Jack
------------------------------------------------------------------------------
Jack W. Howarth, Ph.D.                                    231 Albert Sabin Way
NMR Facility Director                              Cincinnati, Ohio 45267-0524
Dept. of Molecular Genetics                              phone: (513) 558-4420
Univ. of Cincinnati College of Medicine                    fax: (513) 558-8474

Re: -z combreloc

[Andrew Cagney]

> Hello,
>    Debian is preparing to enable -z combreloc
> in their binutils 2.11.92.0.5 packages. On Debian

Would you be better off calling this something like ``2.11.92.debian.5'' 
so that there is no confusion between this and the other N private 
xxx.0.yyy branches kicking around?

Andrew

-z combreloc

[Jack Howarth]

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...

diff -urN binutils-2.11.92.0.5/ld/ldmain.c binutils-2.11.92.0.5.new/ld/ldmain.c
--- binutils-2.11.92.0.5/ld/ldmain.c	Mon Oct  1 18:25:25 2001
+++ binutils-2.11.92.0.5.new/ld/ldmain.c	Sat Oct 13 11:04:23 2001
@@ -249,7 +249,7 @@
   link_info.flags = (bfd_vma) 0;
   link_info.flags_1 = (bfd_vma) 0;
   link_info.pei386_auto_import = false;
-  link_info.combreloc = false;
+  link_info.combreloc = true;
   link_info.spare_dynamic_tags = 5;
 
   ldfile_add_arch ("");

I had a few questions regarding this process of switching over to
using -z combreloc...

1) Exactly which elf targets currently support -z combreloc?
I assume the ones that don't can be fixed if a machine of that
arch is made available to the binutils maintainers.
2) Are there any patches or build changes needed for glibc 2.2.4?
We are currently using glibc 2.2.4 which is a cvs snapshot current
to...

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?

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? 
      Thanks in advance for any information on these
topics.
                     Jack
------------------------------------------------------------------------------
Jack W. Howarth, Ph.D.                                    231 Albert Sabin Way
NMR Facility Director                              Cincinnati, Ohio 45267-0524
Dept. of Molecular Genetics                              phone: (513) 558-4420
Univ. of Cincinnati College of Medicine                    fax: (513) 558-8474