Re: gcc conformance to HP-PA ABI

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

  In message <Pine.GSO.4.05.10007061356400.1693-100000@roadent.sw.stratus.com>y
ou write:
  > gcc is fully compliant with the runtime conventions as far as callability
  > and data sharing.  It uses the registers and frame marker properly, and it
  > does the right things when creating and using function pointers, always a
  > tricky thing on this architecture.  But it does not generate code that
  > complies with HP's unwind conventions.  Specifically:
  > 
  >    * The register save area in the stack frame is not located at its
  > 	standard location at the bottom of the stack frame;
Correct.  This may be correctable by defining a new register and rules
for eliminating it to the stack/frame pointer.  ie, if registers are
saved in the location expected by HP's unwinder library, then the offset
from the frame pointer to local variables varies based on how many
registers are saved.  Thus we can't determine the elimination offset
until we know how many registers we're saving.


  >    * The registers are not saved in the expected order (floats first,
  >         in ascending order, then general registers, in ascending order);
Correct.  And if someone is going to twiddle the FP register saves, then I
would recommend changing them so that they do not use autoincrement
addressing modes since those introduce data dependency stalls.


  >    * The unwind table information being generated from the
  >         compiler-generated .CALLINFO directives is incorrect:
  >           (a) the SAVE_SP argument should not be set when the FP is
  >               manifested in %r3.  It should only be set when the old
  >               SP has been saved at -4 in the frame marker.  Normally,
  >               only low-level assembler code does this.
SAVE_SP is set when the previous stack pointer is stored into the stack;
if I remember correctly that is what HP documented the bit as  meaning and
what GCC actually implements.

  >           (b) The FRAME=n size should be the size of the automatic
  >               storage, not the entire size of the frame.  The size
  >               of the register save area and/or frame marker is not
  >               included in the FRAME=n value.
If you change this, you'll need to fix gdb.  Ugh.  I don't remember, this,
and I don't have my unwinder docs handy to verify.


  >    * Small (<8k) fixed-size stack frames should never have an FP in %r3,
  >         while large fixed-sized frames should always have an FP in %r3.
I wouldn't recommend following this convention.  It's braindead.


  >    * Variable-sized frames should use %r3 or %r4 to remember the old SP,
  >         depending on whether the initial stack frame is small or large.
Similarly.


Also note the HP unwind code assumes that there are no holes in the saved
registers.  ie, saving r3,r4,r6,r7 would be bad since r5 wasn't saved.

HP's unwind code assumes that the prologue has not been scheduled into
user code (which GCC and HP C does when optimizing).

  > If PA-RISC gcc were changed to fix these issues (and I'm not saying that
  > it should be changed), you would be able to use the HP unwind library with
  > gcc generated code.  Even then, you would be restricted to unwinding only
  > from the body of functions.  You would not be able to unwind from, say, a
  > fault in prologue or epilogue code, which the HP unwind library allows.
  > To support prologue and epilogue unwinding, the compiler would have to
  > generate a highly stereotyped series of prologue and epilogue
  > instructions.  HP's runtime architecture document doesn't document these,
  > but instead invites readers to inspect how the HP assembler expands the
  > .ENTER and .LEAVE directives. 
Also note that following those conventions can (and will) have a noticable
impact on performance as they unduly restrict the compiler's ability to
reorder code to avoid pipeline stalls.

.ENTER/.LEAVE are for assembly code writers, not compilers :-)

jeff