This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: A testcase anad a patch for the __gmon_start__ problem on PPC.
On Wed, 11 Oct 2000, H . J . Lu wrote:
> On Wed, Oct 11, 2000 at 12:08:16PM +0200, Franz Sirl wrote:
> > At 05:46 11.10.00, H . J . Lu wrote:
> > >On Tue, Oct 10, 2000 at 08:30:14PM -0700, H . J . Lu wrote:
> > > > to weak undefined. That is the same thing as __gmon_start__ on PPC.
> > > > We don't see the problem on x86 since WEAK_GMON_START is defined for
> > > > x86. Those 2 changes have no impact on x86 as far as __gmon_start__
> > > > is concerned. If we want the binary compatibility, we need to put
> > > > back the weak defined __gmon_start__ for all targets where
> > > > WEAK_GMON_START is not defined before. One way to fix it is to
> > > > provide a PPC initfini.c.
> > > >
> > > >
> > > > H.J.
> > > > ---
> > > > 2000-10-10 H.J. Lu <hjl@gnu.org>
> > > >
> > > > * sysdeps/powerpc/initfini.c: New. For the binary
> > > > compatibility.
> > >
> > >My second thought, since only i386 defines WEAK_GMON_START before, it
> > >seems that all but i386 are affected. Here is a new patch.
> >
> > One question, are you 100% sure that this is no static/shared linker bug?
> > I
>
> I am 99% sure.
Well, I would agree, but what really puzzles me, why the hell is the start of
__gmon_start__ relocated to an absolute branch to 0? I can understand that
the reloc entry pointing to __gmon_start__ gets relocated, but why the first
instruction word(s)?
> > know that my testcase (and probably yours too) fails on x86 and PPC, but
> > succeeds on alpha (btw, can people try that on sparc/arm/m68k please?),
> > which makes me think we may work around a different problem here.
>
> I don't think so. You can call it an ABI bug if you want.
Hmm. Anyway, in what way is your patch different from the previous situation
when WEAK_GMON_START was still honored? Isn't it better to just revert the
responsible patches? Why maintain 2 files if one was enough before?
Franz.