MIPS and the frame pointer (non)chain

[Greg McGary <gkm at eng dot ascend dot com>]

Lack of a frame pointer chain on MIPS makes it somewhat painful to
trace the stack at runtime.  Symbolic debuggers with access to a
complete symbol table can get by, but embedded runtime environments
without reliable ways to find function boundaries have more trouble.

I experimented with `-fno-omit-frame-pointer' hoping this would
persuade gcc to thread a frame pointer chain into the stack.
Unfortunately, it didn't help, because the frame links aren't stored
at a fixed offset in the frame.

Is there any *good* reason why gcc shouldn't save $fp and $ra at a
fixed offset from the current frame pointer?  $fp+(4*gp-reg-size) and
$fp+(5*gp-reg-size) are the natural choices, leaving 4*gp-reg-size
immediately after $fp for the argument build area.  Yes, there is a
pedantic reason, but IMO it's not a *good* one: the MIPS ABI (SysV ABI
MIPS supplement 3ed) states on page 3-15 that "Registers are saved in
numerical order, with higher numbered registers saved in higher memory
addresses".  Furthermore, figure 3-21 on page 3-16 shows that the
floating-point register save area resides at lower address than the
general register save area.  In order for the saved $fp and $ra to be
at fixed offset from the current $fp, the saved GP regs must trade
places with the saved FP regs.

With this change, `-fno-omit-frame-pointer' would give a useable
frame-pointer chain so tracing the stack would require no decoding
of function prologues and would be as simple as it is on Motorola
CPUs.

Is there any reason, in principle, why this change wouldn't be
acceptable for gcc?  If not acceptable as default behavior, how about
as optional behavior?  If it's OK in principle, I'll go ahead and
implement it.  If not, I guess I'll work on the runtime stack
tracer. 8^)

Greg