> You don't need to force the frame pointer on, it is sufficient to say
> that
> ebp needs restoring at the end of the function no matter if it looks
> otherwise
> used or not - and you have to take the frame size impact of the saved
> ebp into
> account.
How does this fit together with the stack realignment code? This is
something I am not sure with yet.
I am considering something like this pseudo code(not done with real coding
yet):
int setup_frame_pointer = frame_pointer_needed;
if(msvc_prolog)
{
emit_insn(gen_movnop(%di)); /* mov %edi, %edi */
emit_insn(gen_msvc_fp(%sp, %bp)); /* push %esp; mov %esp, %ebp */
if(frame_pointer_needed && !( crtl->drap_reg &&
crtl->stack_realign_needed))
{
setup_frame_pointer = 0;
}
else
{
emit_insn(gen_revert_msvc_fp(%bp)); /* pop %ebp */
}
}
/* ... */
stack realignment code here
/* ... */
if(setup_frame_pointer /* used to be frame_pointer_needed */) {
/* Normal fp setup code */
}
Basically the idea is that if the frame pointer is set up there's this code
mov.s %edi, %edi
push %ebp
mov.s %esp, %ebp
; frame pointer already set up, continue with normal code. Nice and pretty
If the frame pointer is not needed:
mov.s %edi, %edi
push %ebp
mov.s %esp, %ebp
pop %ebp
; Continue normally here. I think that case can't be improved too much,
since the msvc_prolog stuff modifies the base pointer.
Now my problem: If the frame pointer is needed, and the stack realignment is
needed:
mov.s %edi, %edi
push %ebp
mov.s %esp, %ebp
pop %ebp
leal ...
push %ebp
mov %esp, %ebp
This doesn't look pretty, really.
> Moreover, if your prologue beings with an unspec_volatile that emits
> the
> three-instruction sequence you want, the optimizers should leave it
> there
> at the start of the function.
> Although it is properly easiest to get debug and unwind information
> right
> if you make this three separate unspec_volatile patterns, with their
> respective REG_FRAME_RELATED_EXPR notes where applicable.
> I.e. the push ebp saves ebp and changes the stack.
> The mov.s esp,ebp needs a REG_FRAME_RELATED_EXPR note only if you are
> actually using a frame pointer.
The REG_FRAME_RELATED_EXPR is set with this, right: ?
RTX_FRAME_RELATED_P (insn) = 1;
I haven't yet figured out what it does exactly.
Another issue is 64 bit. I guess if I use the hard_frame_pointer_rtx,
stack_pointer_rtx and similar register indentifiers and pass it to the
gen_XXXX functions I should get proper code for both 32 and 64 bit, right?
Besides that I still have to look if Windows has such a hooking-friendly
function prologue on Win64 too, or if that is just a 32 bit issue.
