Re: CFI directives and dynamic stack alignment

[Alan Modra <amodra at gmail dot com>]

On Mon, Aug 17, 2015 at 10:38:22AM -0700, Steve Ellcey wrote:
> On Tue, 2015-08-11 at 10:05 +0930, Alan Modra wrote:
> 
> > > The 'and' instruction is where the stack gets aligned and if I remove that
> > > one instruction, everything works.  I think I need to put out some new CFI
> > > psuedo-ops to handle this but I am not sure what they should be.  I am just
> > > not very familiar with the CFI directives.
> > 
> > I don't speak mips assembly very well, but it looks to me that you
> > have more than just CFI problems.  How do you restore sp on return
> > from the function, assuming sp wasn't 16-byte aligned to begin with?
> > Past that "and $sp,$sp,$3" you don't have any means of calculating
> > the original value of sp!  (Which of course is why you also can't find
> > a way of representing the frame address.)
> 
> I have code in expand_prologue that copies the incoming stack pointer to
> a temporary hard register and then I have code to the entry_block to
> copy that register into a virtual register.  In the exit block that
> virtual register is copied back to a temporary hard register and
> expand_epilogue copies it back to $sp to restore the stack pointer.

OK, then you need to emit a .cfi directive to say the frame top is
given by the temp hard reg sometime after that assignment and before
sp is aligned in the prologue, and another .cfi directive when copying
to the pseudo.  It's a while since I looked at the CFI code in gcc,
but arranging this might be as simple as setting RTX_FRAME_RELATED_P
on the insns involved.

If -fasynchronous-unwind-tables, then you'll also need to track the
frame in the epilogue.

> This function (fn2) ends with a call to abort, which is noreturn, so the
> optimizer sees that the epilogue is dead code and GCC determines that
> there is no need to save the old stack pointer since it will never get
> restored.   I guess I need to tell GCC to save the stack pointer in
> expand_prologue even if it never sees a use for it.  I guess I need to
> make the temporary register where I save $sp volatile or do something
> else so that the assignment (and its associated .cfi) is not deleted by
> the optimizer.

Ah, I see.  Yes, the temp and pseudo are not really dead if they are
needed for unwinding.

-- 
Alan Modra
Australia Development Lab, IBM