Re: gcc conformance to HP-PA ABI

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

  In message <Pine.GSO.4.05.10007061654300.1693-100000@roadent.sw.stratus.com>y
ou write:
  > I agree.  You'll still see the PA2.0 HP compilers using autoincrement,
  > though, in order to preserve unwindability of prologues and epilogues.
Presumably for their unwind library (which FWIW, it's used by their
gdb based debugger to the best of my knowledge).


  > >   >    * 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 an
  > d
  > > 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."
My recollection was based on the stack unwind library document.  Probably
the definitive definition can be found on HP's web site (I believe there's
unwinder information on it now).

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


  > >   >           (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.
gdb looks at unwind tables to get hte stack size and a guess at the registers
it needs to dig out of the stack.  It's been looking at unwind tables since
about 1993 or 1994.

  > 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.
I have :-)  Most commonly it'll omit saving r3, but it could just as well
omit another.

  > 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.
Yup.  Actually it'd be nice to generate whatever bits we need to deal with
multiple exit points.  But then again, the PA doesn't have the appeal to me
it once did, so I rarely do anything other than try to keep it running :-)


  > > 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.
I'm not sure when they do it -- I know they've got an explicit option for it.
Yes, gcc does it anytime you turn the scheduler on.


  > > Also note that following those conventions can (and will) have a noticabl
  > e
  > > 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.
It's come up from time to time -- usually folks give up soon after they
start digging into the issues :(


Cheers,
jeffv