Re: Versioning mess proved!!!

[Geoff Keating <geoffk at cygnus dot com>]

> From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
> Date: Sun, 1 Oct 2000 23:08:28 +0200
> Cc: Ulrich Drepper <drepper@redhat.com>, Jack Howarth <howarth@fuse.net>,
>         libc-alpha@sourceware.cygnus.com, aj@suse.de
> 
> On Sun, 01 Oct 2000, Philip Blundell wrote:
> > >Uli, actually I think your patch broke this, WEAK_GMON_START was never
> > >defined for PPC, we always had the dummy weak __gmon_start__() routine
> > > which Philips patch removed. Can we really change this without breaking
> > > binary compatibility?
> >
> > I thought Geoff said at the time that PPC worked OK without the dummy weak
> > definition.  What's the actual issue that breaks it?
> 
> Backwards compatibility? Actually I can't do much better in this area, cause 
> the innards of the shared library loading are still mostly a mystery to me. 
> Maybe it's not possible to have backwards compatibility, maybe the shared lib 
> loader has a bug, maybe...? I think Geoff is the one to ask here, or maybe 
> somebody can give me some hints on what to look next.

I believe it's either a bug in ld.so or a bug in the binutils.

If someone could show me the output of 

objdump -R zlib.so | grep gmon_start

I could probably guess which one it is.

> What I know is that libc-2.1.94 + zlib.so-compiled-against-2.1.94 + 
> zlib-example-compiled-against-2.1.3 segfaults on PPC.
> The segfault happens in call_gmon_start, cause *gmon_start is not zero. It 
> seems like *gmon_start got relocated to a "ba 0", that's an absolute branch 
> to 0 on PPC, which naturally segfaults.
> 
> Well, maybe I should ask the other way round, are there any advantages of the 
> current code to the previous one? Does PPC have to change at all?

It doesn't matter.  User code could use this construct too, and it
should work.

-- 
- Geoffrey Keating <geoffk@cygnus.com>