This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Versioning mess proved!!!


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]