Re: gcc conformance to HP-PA ABI

[Richard Boylan <boylan at sw dot stratus dot com>]

On Fri, 30 Jun 2000, Jeffrey A Law wrote:
>   In message <200006301450.QAA27567@ubu.enst.fr>you write:
>   > I am currently investigating the possibility to use a hp library to unwind
>   > stack frames. This library requires that the code respects some conventions
>   > regarding how registers are used, where they are saved, ...
> Right.  Note however that such conventions are not part of the ABI -- the
> ABI is concerned with parameter passing, structure layout, caller vs called
> saved register and similar items.
> 
>   > Using gcc 2.95.1 19990816 (release) on HP-UX 10.20, successful results are
>   > only obtained when using the -fomit-frame-pointer option.
> Odd, since -fomit-frame-pointer does _not_ save the previous stack pointer
> into the frame.  
> 
> Either way, HP's unwind libraries should be able to deal with code that
> does or does not have a frame pointer.  To the best of my knowledge GCC
> follows the unwinder's conventions as far as the SAVE_SP directives
> are concerned.
> 
>   >  Indeed, the
>   > generated assembly for a simple test case shows that, when this option is
>   > not provided, some SAVE_SP directives appear and sp is actually saved, but
>   > not at the "conventional" place (if I understand correctly).
> ?!?  I think you're badly confused.  -fomit-frame-pointer will (usually)
> prevent the compiler from saving the previous stack pointer into the frame.
> 
>   > Is it normal ? Did I miss something ? In case no, are there other known
>   > cases in which the hp conventions may not be followed ?
> The location of the callee save area is different which makes the unwinder
> code unable to find callee saved registers.


Documentation on the HP-UX PA-RISC runtime conventions can be found off
http://devresource.hp.com/devresource/Docs/DocLibrary.html.  When
reading them, it helps to remember that they were originally written for
HP Pascal, not C, running on MPE, not HP-UX.  Hence the emphasis on code
unwinding, and the initial omission (and later addition) of variable-sized
stack frames and shared libraries.

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;

   * The registers are not saved in the expected order (floats first,
        in ascending order, then general registers, in ascending order);

   * 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.
          (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.

   * 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.

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

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. 
              


Richard Boylan
Stratus Computer
Maynard, Massachusetts USA
boylan@sw.stratus.com