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: Linus Torvalds <torvalds at linux-foundation dot org>
- To: Frederic Weisbecker <fweisbec at gmail dot com>
- Cc: Steven Rostedt <rostedt at goodmis dot org>, 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 12:36:25 -0800 (PST)
- 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>
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.
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.
Linus