This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: BUG: GCC-4.4.x changes the function frame on some functions
- From: Steven Rostedt <rostedt at goodmis dot org>
- To: Linus Torvalds <torvalds at linux-foundation dot org>
- Cc: Frederic Weisbecker <fweisbec at gmail dot com>, David Daney <ddaney at caviumnetworks dot com>, Andrew Haley <aph at redhat dot com>, Richard Guenther <richard dot guenther at gmail dot com>, Thomas Gleixner <tglx at linutronix dot de>, Ingo Molnar <mingo at elte dot hu>, "H. Peter Anvin" <hpa at zytor dot com>, LKML <linux-kernel at vger dot kernel dot org>, Andrew Morton <akpm at linux-foundation dot org>, Heiko Carstens <heiko dot carstens at de dot ibm dot com>, feng dot tang at intel dot com, Peter Zijlstra <peterz at infradead dot org>, jakub at redhat dot com, gcc at gcc dot gnu dot org
- Date: Thu, 19 Nov 2009 15:44:24 -0500
- Subject: Re: BUG: GCC-4.4.x changes the function frame on some functions
- References: <1258653562.22249.682.camel@gandalf.stny.rr.com> <84fc9c000911191003t244eb864o3d5b355ab5485f@mail.gmail.com> <4B058CCD.8050605@redhat.com> <alpine.LFD.2.00.0911191039470.2793@localhost.localdomain> <alpine.LFD.2.00.0911191041471.2793@localhost.localdomain> <alpine.LFD.2.00.0911191047350.2793@localhost.localdomain> <4B05982B.6060200@caviumnetworks.com> <1258658886.22249.874.camel@gandalf.stny.rr.com> <20091119194625.GE4967@nowhere> <1258661141.22249.962.camel@gandalf.stny.rr.com> <20091119202526.GG4967@nowhere> <alpine.LFD.2.00.0911191227250.2793@localhost.localdomain>
- Reply-to: rostedt at goodmis dot org
On Thu, 2009-11-19 at 12:36 -0800, Linus Torvalds wrote:
>
> On Thu, 19 Nov 2009, Frederic Weisbecker wrote:
> >
> > > That way the lr would have the current function, and the parent would
> > > still be at 8(%sp)
> >
> > Yeah right, we need at least such very tiny prologue for
> > archs that store return addresses in a reg.
>
> Well, it will be architecture-dependent.
Totally agree, as mcount today is architecture dependent.
>
> For example, alpha can store the return value in _any_ register if I
> recall correctly, so you can do the "call to __fentry__" by just picking
> another register than the default one as the return address.
>
> And powerpc has two special registers: link and ctr, but iirc you can only
> load 'link' with a branch instruction. Which means that you could do
> something like
>
> mflr 0
> bl __fentry__
>
> in the caller (I forget if R0 is actually a call-trashed register or not),
> and then __fentry__ could do something like
>
> mflr 12 # save _new_ link
> mtlr 0 # restore original link
> mtctr 12 # move __fentry__ link to ctr
> .. do whatever ..
> bctr # return to __fentry__ caller
>
> to return with 'link' restored (but ctr and r0/r12 trashed - I don't
> recall the ppc calling conventions any more, but I think that is ok).
>
> Saving to stack seems unnecessary and pointless.
I was just using an example. But as you pointed out, each arch can find
its best way to handle it. Having the profiler called at the beginning
of the function is what I feel is the best.
We also get access to the function's parameters :-)
-- Steve