This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Versioning mess proved!!!
- To: Franz dot Sirl-kernel at lauterbach dot com
- Subject: Re: Versioning mess proved!!!
- From: Geoff Keating <geoffk at cygnus dot com>
- Date: Sun, 1 Oct 2000 14:39:20 -0700
- CC: drepper at redhat dot com, howarth at fuse dot net, libc-alpha at sourceware dot cygnus dot com, aj at suse dot de
- References: <39D50E20.263F646F@fuse.net> <00093002244100.04124@enzo.bigblue.local> <m3wvftmqor.fsf@otr.mynet.cygnus.com> <00100113471400.01064@enzo.bigblue.local>
> From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
> Date: Sun, 1 Oct 2000 13:47:14 +0200
> 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.
Is __gmon_start__ defined anywhere? If not, it should be zero. If it
is, both should be the same.
> 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.
I think this is just papering over a bug somewhere else.
--
- Geoffrey Keating <geoffk@cygnus.com>