HP-PA ABI issues - framepointer handling

[Jeffrey A Law]

  In message < 20001018203501.3D9A934D81@nile.gnat.com >you write:
  > 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.
More correctly, the ABI defines things that really don't belong in
the ABI.  ie, the areas where we deviate do not affect the ability to
mix code from one toolchain to another.  They only affect the lame HP
unwinder.

  > 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 A
  > BI!)
  >   sp -> r3       (ok, we can use this as fp locally, nothing wrong with tha
  > t)
  >  {r1 -> (sp)     (double wrong? r1 may not contain old fp, and we should fi
  > rst
  >                   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 originall
  > y
  > 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?
Do a search on the archives.  Most of this stuff was discussed a while
ago.  I'm certainly open to changes where we don't impact performance
on the PA, but if we're going to do something that impacts performance
for the sole purpose of making HP's lame unwinder work, then it'll need
some discussion.

One thing that we should be able to do is at least get the register
saves into the same place as the HP compiler.  We'll have to define a
new "hard" register and eliminate it to the FP or SP, it shouldnt' be
that hard, but I wasn't aware of how to do that way back when I wrote
the prologue/epilogue code.

Jeff