Re: HP-PA ABI issues - framepointer handling

[Jeffrey A Law <law at cygnus dot com>]

  In message <20001019121744.4A7D734D8D@nile.gnat.com>you write:
  > On Wed, 18 Oct 2000 20:16:49 -0600, Jeffrey A Law wrote:
  > 
  >   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.
  > 
  > Defining a way to unwind is definately something that does belong 
  > in an ABI, as it is necessary to properly propagate exceptions across
  > code compiled with different compilers.
Not if you write a reasonable unwinder.

If this kind of stuff is going to be ABI mandated, then the way to go is
to mandate a section of tables to ease unwinding, not code sequences for
the prologue/epilogue that the compiler must follow.  HP tried to build a
suitable unwind table description, but wasn't particularly successful.

I strongly recommend you look at how dwarf2 unwinders work and use those
for unwinding.  If you find that you're in code without a dwarf2 unwinder
table, then look at alternate strategies for unwinding the stack, which
might involve looking at the HP unwind info, disassembling code, whatever.

  > I am aware of the earlier discussions, but I did not know we don't
  > even save the framepointer in the right location.

  > There definately
  > is something between exactly getting all unwinding stuff right, and
  > not even saving the framepointer in its proper position.
I'm guessing you actually mean the previous stack pointer, not the
frame pointer here.

99.9% of the time the previous stack pointer is the current stack pointer
minus the size of the current frame.  No frame pointer needed, no need to
store the previous stack pointer into the stack.

For the cases where it is needed (dynamic frames), the previous stack pointer
is copied into %r3 which then serves as a frame pointer.  The old value in
%r3 is saved via normal callee register saves.

  > I think that's indeed a worthwhile goal, so I'll go ahead and see what
  > can be done without sacrificing performance.
We should be able to do this without any performance impact.  I just didn't
know enough about register eliminations to be able to do it years ago when
I wrote the code.

  > Also, on that note,
  > it seems that we can save two instructions in the prologue for functions 
  > that do not do dynamic stack allocations (alloca), by not having to
  > maintain the GCC convention of passing the framepointer.
You'll find that when optimizing gcc doesn't maintain a framepointer for
such functions.

jeff