This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Versioning mess proved!!!
> 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>