This is the mail archive of the
mailing list for the GCC project.
Re: function arguments offset computation with -fomit-frame-pointer
- From: Bernardo Innocenti <bernie at develer dot com>
- To: Jim Wilson <wilson at tuliptree dot org>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 8 Jul 2003 08:19:55 +0200
- Subject: Re: function arguments offset computation with -fomit-frame-pointer
- Organization: Develer
- References: <email@example.com> <3F0A2E4B.firstname.lastname@example.org>
On Tuesday 08 July 2003 04:36, Jim Wilson wrote:
> Only reload needs to know about frame offsets.
Thank you very much for the detailed explanation. Now it's much
more clear to me.
> > I also have a more m68k-specific question: the code path for
> > creating room for the frame when no frame pointer always adds 4
> > bytes to the required frame size. Is that done to get the same
> > offset that link/unlink would have done? Why is that necessary?
> Probably nobody knows anymore, it has been there for well over a
> decard, but link/unlink space for the return address is the obvious
> guess. Maybe the problem is that INITIAL_FRAME_POINTER_OFFSET isn't
> checking frame_pointer_needed, and thus we always need to add the 4
> bytes to make INITIAL_FRAME_POINTER_OFFSET work? If so, then fixing
> that macro would let you get rid of the extra 4 bytes in the prologue
I think I need why it's needed on Linux: there's code in the kernel that
needs to examine the stack frame and it assumes the 4 bytes for saving
the old frame pointer are always there. The kernel chokes if I remove them.
// Bernardo Innocenti - Develer S.r.l., R&D dept.
Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html