Re: gcc conformance to HP-PA ABI

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

On Thu, 6 Jul 2000, Jeffrey A Law wrote:

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

I agree.  You'll still see the PA2.0 HP compilers using autoincrement,
though, in order to preserve unwindability of prologues and epilogues.

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

gcc does save the previous sp, but not in the location expected by the
save_sp bit:

HP Assembler Manual, 5th ed: "SAVE_SP specifies that the current routine
saves the value of Previous_SP in its frame marker at SP-4.  Because the
assembler does not automatically save the stack pointer when it generates
entry/exit code sequences, you must explicitly save this value in your
program when using this key word."

HP Runtime Architecture Document, HP-UX 11.00: "save_sp (bit 27 [in an
unwind table entry]): On if the entry value of the sp is saved by this
region's entry sequence in the current frame marker (current_sp-4); zero
otherwise."

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

I didn't think gdb looked at the unwind tables.  I thought it derived
unwind info from grovelling through prologue code, which would make it
immune to this change.


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

I didn't write it, I didn't endorse it, I'm only reporting the facts....


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

Correct.  But I've never seen a case where gcc hasn't obeyed this.

Another thing I didn't mention: gcc doesn't put the .EXIT in the same
place where HP C and the HP assembler put them.  gcc puts them after the
instruction in the delay slot of the BV. HP puts them between a BV and its
delay slot.  This only affects unwindability of epilogues, though.

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

It's been a while since I've used HP C, but I believe that prologue
scheduling had to be explicitly turned on, or else it only came on at the
very highest (+O4 ie +Obenchmark :-) ) optimization level.  In gcc,
there's no way to turn off prologue scheduling unless you turn off
scheduling entirely.

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

gcc for PA-RISC's been out there a long time, and this is the first I've
heard of anybody trying to get it to work with HP's idiosyncratic unwind
library.  I'm not advocating changing gcc to make it unwindable.  If
implemented as an -m option, it would be rarely used, I suspect.

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