This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Versioning mess proved!!!
- To: Ulrich Drepper <drepper at redhat dot com>
- Subject: Re: Versioning mess proved!!!
- From: Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>
- Date: Sun, 1 Oct 2000 18:12:39 +0200
- Cc: Jack Howarth <howarth at fuse dot net>,libc-alpha at sourceware dot cygnus dot com,aj at suse dot de
- References: <39D50E20.263F646F@fuse.net> <m3wvftmqor.fsf@otr.mynet.cygnus.com> <00100113471400.01064@enzo.bigblue.local>
On Sun, 01 Oct 2000, Franz Sirl wrote:
> > On Sun, 01 Oct 2000, Ulrich Drepper wrote:
> > Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:
> > > Hmm, it segfaults in call_gmon_start cause __gmon_start__ gets
> > > relocated and thus is no longer NULL.
> >
> > Why is this bad? I know it's not wanted but why should a performed
> > relocation cause the trouble? Is there an incorrect implementation of
> > __gmon_start__ somewhere?
>
> Well, I wish I knew exactly what happens...
> It seems that under some combinations of glibc-2.1.3/glibc-2.2 and thus a
> mixture of NOTYPE/WEAK and FUNC/WEAK definitions the start of
> __gmon_start__ gets relocated, whereas it should stay a 0. It get's
> relocated to an absolute branch to address 0. Since now the test for 0 in
> call_gmon_start fails, __gmon_start__ gets called and then branches to 0
> which nicely segfaults.
>
> > > murx22: 0001e994 08114 R_PPC_GLOB_DAT 00000000 __gmon_start__
> > > + 0
> > > murx22: 129: 00000000 0 NOTYPE WEAK DEFAULT UND
> > > __gmon_start__ murx22: 248: 00000000 0 NOTYPE WEAK DEFAULT
> > > UND __gmon_start__
> >
> > This is what we have on x86 as well and it works just fine. I need
> > some more information.
>
> But do you get the NOTYPE/WEAK under glibc-2.1.3 as well? And under earlier
> glibc-2.1.9x snapshots? Actually I think you fixed it with that patch for
> PPC:
My misunderstanding, this one broke it :-). What was the reason for this
patch?
> 2000-08-28 Ulrich Drepper <drepper@redhat.com>
>
> * sysdeps/unix/sysv/linux/powerpc/Makefile [$(subdir)==csu]
> (CFLAGS-initfini.s): Add -DWEAK_GMON_START.
>
> but then the dummy function in initfini.c go completely removed with this
> patch:
>
> 2000-09-10 Ulrich Drepper <drepper@redhat.com>
>
> * sysdeps/generic/initfini.c: Rewrite slightly to get rid of the
> ugly GMON_WEAK_START hack.
> Patch by Philip Blundell <philb@gnu.org>.
>
> and WEAK_GMON_START is now completely unused.
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'm not sure about the implications, but maybe this can be solved with the
> appended patch? At least it shouldn't hurt to be explicit about the type of
> __gmon_start__ and it looks a bit cleaner that way. I'll try that now on
> PPC.
Didn't help. So can we just go back to the old setup and revert both patches?
The current setup even generates much worse code than the old one. What was
the reason to do this on PPC?
Franz.