HP-PA ABI issues - framepointer handling

[Geert Bosch]

In order to be able to do reliable stack-traces on HP-PA, we need to
be able to walk the chain of stack-frames, but it appears that currently 
we don't quite follow the ABI on HP.

The issue is that GCC does not have the frame-marker stored at the top of 
the stack when calling functions. This 8-word frame-marker should contain 
(at least) the pointer to the old SP, which is needed to be able to trace 
the frames.

Instead of relying on the framer-marker being correct, GCC uses a general 
purpose register (R3) to pass the frame-pointer to functions that it calls.

This leads to a prologue doing the following:
  rp -> -20(sp)  (ok, following ABI)
  r3 -> r1       (r3 is assumed to contain the old fp, but this is not in ABI!)
  sp -> r3       (ok, we can use this as fp locally, nothing wrong with that)
 {r1 -> (sp)     (double wrong? r1 may not contain old fp, and we should first
                  do the increment but actual insn is postincrement?)
  sp+fsize -> sp}(ok, reserve size for frame, last part of atomic insn)
  
It seems this might have been done because when the HPPA port was originally
done, GCC didn't have the necessary infrastructure required for maintaining
the frame-marker.

As the RS-6000 ABI has a similar way of saving the chain of frame pointers 
(and gcc follows that ABI exactly), I would think it might be the
right time to go back and see if we can change the HPPA port to follow
the ABI and not assume that r3 contains the framepointer.

Jeff, as you know most about the HP port, could you comment on whether
or not it makes sense to more closely follow the HPPA ABI, and on what 
potential pitfalls there might be?

Regards,
   Geert