This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Is glibc branch now frozen?
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Andrew Haley <aph at redhat dot com>
- Cc: binutils at sources dot redhat dot com
- Date: Thu, 5 Jun 2003 11:02:58 -0400
- Subject: Re: Is glibc branch now frozen?
- References: <20030512.160216.576022219.rene.rebe@gmx.net> <20030512142959.GO2166@bubble.sa.bigpond.net.au> <20030512.192728.783375904.rene.rebe@gmx.net> <20030512175651.GA17873@nevyn.them.org> <16063.58443.923999.361502@masala.cambridge.redhat.com> <20030512181746.GA18691@nevyn.them.org> <16063.61390.312183.767021@masala.cambridge.redhat.com>
On Mon, May 12, 2003 at 08:02:38PM +0100, Andrew Haley wrote:
> Daniel Jacobowitz writes:
> > On Mon, May 12, 2003 at 07:13:31PM +0100, Andrew Haley wrote:
> > > Daniel Jacobowitz writes:
> > > > On Mon, May 12, 2003 at 07:27:28PM +0200, Rene Rebe wrote:
> > > > > On: Mon, 12 May 2003 23:59:59 +0930,
> > > > > Alan Modra <amodra@bigpond.net.au> wrote:
> > > > > > On Mon, May 12, 2003 at 04:02:16PM +0200, Rene Rebe wrote:
> > > > > > > unresolvable R_PPC_ADDR32 relocation against symbol `timezone@@GLIBC_2.0'
> > > > > >
> > > > > > See http://sources.redhat.com/ml/binutils/2003-04/msg00488.html
> > > > >
> > > > > In which binutils release should this change show up?
> > > >
> > > > 2.14, due out shortly. Once we finish testing the branch; probably
> > > > another week or two.
> > >
> > > Ah, I didn't realize that binutils release was so close.
> > >
> > > I have a patch for the branch that really ought to go in. rth has
> > > already seen it and okayed it for trunk and branch, but I haven't
> > > checked it in yet. It's a patch to elf_hash(), which can in some
> > > circumstances return results different from the elf_hash() routine in
> > > glibc, and thus symbols aren't found in DSOs.
> > >
> > > Is the branch frozen?
> >
> > Not really. I don't remember ever seeing your patch; could you post
> > it? It sounds like it should be included.
>
> The disparity can only occur (with fairly low probability) on a
> machine that has a 64-bit long. I was going to post it to binutils,
> but I hadn't got around to it.
OK, I'll bite.
Can you give an example where this patch makes any difference? It
appears that h should never, ever exceed 0xffffffff anyway.
> 2003-05-07 Andrew Haley <aph@redhat.com>
>
> * elf.c (bfd_elf_hash): Mask lower 32 bits of hash.
>
> --- bfd/elf.c~ 2003-05-06 18:15:30.000000000 +0100
> +++ bfd/elf.c 2003-05-07 17:50:52.000000000 +0100
> @@ -265,7 +265,7 @@
> h ^= g;
> }
> }
> - return h;
> + return h & 0xffffffff;
> }
>
> /* Read a specified number of bytes at a specified offset in an ELF
>
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer