Re: Frame-related delay slot insns

[Richard Sandiford <rsandifo at redhat dot com>]

Richard Henderson <rth@redhat.com> writes:
> On Wed, May 07, 2003 at 07:13:15AM +0100, Richard Sandiford wrote:
> > Say one adjusts the stack and another has an sp-relative store.
> 
> In theory, all of the stores as described in the dwarf2 data
> are CFA relative, not SP relative.  If the adjustment and the
> store are represented at the same ip address, things will
> still work out fine.

I can see that's true in the final unwind info.  I was thinking
more of the order in which insns were passed to dwarf2out.c.

E.g., if we pretend that the mips call insn has two delay slots and
(for whatever reason!) we have a sequence such as:

        move $2,$31
        jal foo                 # A
        addiu $sp,$sp,-64       # B
        sw $2,32($sp)           # C

then as I understand it, calling:

        dwarf2out_frame_debug (B);
        dwarf2out_frame_debug (C);

would give different frame info to:

        dwarf2out_frame_debug (C);
        dwarf2out_frame_debug (B);

even when the labels associated with B and C are at the same address.
The first sequence would be right, the second would be wrong.  In the
second case, the unwind info would say that $4 is stored outside the
function's frame.

I thought the same sort of situation might occur if (on some
architecture) the call itself had effects that were described
in the unwind info.  Then the relative order of calls might matter.

        dwarf2out_frame_debug (A);
        dwarf2out_frame_debug (B);

might not generate the same unwind info as:

        dwarf2out_frame_debug (B);
        dwarf2out_frame_debug (A);

Of course, I could be talking rubbish here. ;)

> > ... it sounds like both of the patches I posted should do what I want.
> > I guess the second one is a bit cleaner.
> 
> I've gotten lost.  Which patch was this?

http://gcc.gnu.org/ml/gcc-patches/2003-05/msg00525.html

Richard