Subject: Binutils 2.9.x

From: [email-masked]
Date: Mon, 9 Nov 1998 14:03:41 +0100

I've been asked if I recommend an upgrade to binutils 2.9.x when I recently
posted patches.  No, at this time I even disrecommend an upgrade since
binutils 2.9.1.0.4 have been the most buggy binutils version I touched since
a long, long time.  Rebuilding glibc 2.0.99 triggers more than 3000 lines
warning messages for failed assertions in elf32-mips.c, I get core dumps and
all sorts of sick effects.

I touched them though for two reasons.  First of all, in the interest of
getting an Linux distribution working for us with as little changes as
possible we should go with whatever the Linux distributor uses.  In case
of Redhat 5.1 this is binutils 2.9.1.0.4.  Second I've started to work a bit
on glibc 2.0.99.  In order to get symbol versioning working we need at
least binutils 2.9.1.

  Ralf

---

From: [email-masked]
Date: Thu, 12 Nov 1998 00:31:03 +0100

On Wed, Nov 11, 1998 at 09:57:09AM +0100, Philip Blundell wrote:

> Does this happen even without versioning?  My experience with the ARM was that 
> when we tried to start using symbol versioning it showed up various problems 
> in our ELF backend (basically various invalid assumptions).  All were easy to 
> fix but gave symptoms like yours initially.

It's several bugs all in one.  First of all somebody broke the special
handling for the .reginfo sections.  We actually only have them to satisfy
the ABI, otherwise they're toxic waste since nothing uses them.  Then we
have the missing support for symbol versioning.  All the assert messages
I examined were caused by the dynindx field of symbol hash being set to -1
in order to force them to local symbols.  Finally we have a other bugs
which account for the core dumps.  So far I only have the .reginfo thing
fixed and since my knowledge about BFD internals has mostly decayed of the
long time getting the symbol versioning bugs right has proven to be quite
some work.

  Ralf