Re: A testcase anad a patch for the __gmon_start__ problem on PPC.

[Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>]

At 22:45 11.10.00, Geoff Keating wrote:
> > On Wed, 11 Oct 2000, H . J . Lu wrote:
> > > On Wed, Oct 11, 2000 at 09:34:44PM +0200, Franz Sirl wrote:
> > > > > 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?
> > >
> > > The difference is if you do nothing, you will get the clean code. If
> > > you want the binary compatibility, you can use the old one.
> >
> > What if I want both the clean code and backwards compatibility? Go with my
> > suggested solution? I tested that (one minor mod) with my testcase and it
> > works fine. It depends on the fact that space is allocated for 
> __gmon_start__
> > and initialized to 0. The first 2 words maybe touched by relocation, but
> > starting with the 3rd word it stays at 0, which is an illegal opcode 
> for PPC
> > and thus no valid __gmon_start__ routine is there.
> > I wonder though how the size of the __gmon_start__ function gets 
> calculated
> > for allocation.
>
>Aah, that's what the code was doing!
>
>OK, this is slightly wrong.  The right test would be that the first
>instruction at __gmon_start__ is 'bl,a 0'.

Yes, either that or 'addi r11,r0,xxxx' for lazy relocation (as HJ noted). 
The test for 0 actually was meant as a shortcut to avoid doing 2 compares, 
but this cannot work when  gmon_start points to a PLT entry and not the 
real function as I thought. I'll do a real patch and test it.


>Now that I know what it's doing, I think this is an OK workaround.
>It's probably better than falling back to the old way of doing
>__gmon_start__, since that has problems with shared object unloading.
>
>(However, I'm now working on a proper fix, which is to make weak
>symbols work correctly in executables in the first place, at least in
>-fpic code.)

Ah, a real fix would certainly be nice, thanks.

Franz.