This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
How can INITIAL_FRAME_POINTER_OFFSET be made correct?
- From: "Dave Korn" <dk at artimi dot com>
- To: <gcc at gcc dot gnu dot org>
- Date: Fri, 19 Mar 2004 15:30:03 -0000
- Subject: How can INITIAL_FRAME_POINTER_OFFSET be made correct?
Erm. Bit confused here.
INITIAL_FRAME_POINTER_OFFSET is supposed to be "the difference between the
frame pointer and the stack pointer values immediately after the function
prologue", according to gccint. It goes on to suggest
" The value would be computed from information such as the result of
`get_frame_size ()' and the tables of registers `regs_ever_live' and
`call_used_regs'. "
INITIAL_FRAME_POINTER_OFFSET is called before the md emit prologue
function has has a chance to run. So it has to duplicate the exact
calculations that the prologue function does when it's deciding on the stack
frame layout for the current function.
In the particular port I'm working with, we decide whether or not to
allocate a stack slot for saving the link register according to whether or
not we ever use it - i.e. we use code that looks like:
info->lr_save_size = !current_function_is_leaf ||
regs_ever_live[LINK_REGNUM] ? 4 : 0;
[info is just a struct where I'm keeping the sizes and offsets of the
various areas of the stack frame].
There's a bit of a problem, however. regs_ever_live[LINK_REGNUM] is zero
when INITIAL_FRAME_POINTER_OFFSET is called, but something has set it to one
by the time we get to the emit prologue function. The result is that the
two of them disagree about the size and layout of my stackframes, and I get
a lot of FAILs in the varargs tests.
Is it valid that regs_ever_live[] changes between IFPO and emit_prologue?
If so, the documentation should warn *against* using it in IFPO. If not,
I've got to get finding out why it changes when it shouldn't.......
cheers,
DaveK
--
Can't think of a witty .sigline today....