Re: gcc conformance to HP-PA ABI

Re: gcc conformance to HP-PA ABI

[Richard Kenner]

    I should think that the overhead of the HP unwind library would be
    higher than the overhead of setjmp/longjmp.

Do you mean overhead when an exception *occurs* or in going into a region
with an exception handler?

setjmp/longjmp is very efficient for handling the exception, but
extremely inefficient in programs where the exceptio doesn't occur
(the main cost is that the location of the setjmp buffer is
thread-specific data).

Re: gcc conformance to HP-PA ABI

[Jeffrey A Law]

  In message < 10007081218.AA14728@vlsi1.ultra.nyu.edu >you write:
  >     Better to hack it in the direction we'd like to go (dwarf2 unwinders)
  >     than in a direction we do not want to go (compatible with HP's
  >     unwinder library).
  > 
  > Why is that a direction we don't want to go?  Isn't it always better for GC
  > to be compatible with as many vendor features as possible?  Shouldn't we be
  > able to mix vendor- and GCC-built object files when processing exceptions?
  > 
  > What about linking with third-party libraries and propagating exceptions
  > through them?  Wouldn't that be simpler if using HP's unwinder library?
What's the point of even trying given our C++ ABI isn't even close to
compatibility with HP's C++ compiler?

What's the point when (to the best of my knowledge) that's not the unwinding
code used by HP for unwinding from exceptions?

What's the point when the conventions for the unwinder place unreasonable
restrictions on code generation?

What's the point when HP itself wants to move more towards standards like
dwarf2 than their own one of a kind implementation?

Jeff

Re: gcc conformance to HP-PA ABI

[Richard Kenner]

    Better to hack it in the direction we'd like to go (dwarf2 unwinders)
    than in a direction we do not want to go (compatible with HP's
    unwinder library).

Why is that a direction we don't want to go?  Isn't it always better for GC
to be compatible with as many vendor features as possible?  Shouldn't we be
able to mix vendor- and GCC-built object files when processing exceptions?

What about linking with third-party libraries and propagating exceptions
through them?  Wouldn't that be simpler if using HP's unwinder library?

Re: gcc conformance to HP-PA ABI

[Olivier Hainque]

> 
> 
>   In message < 20000707175220.927DE5F5F6@dublin.ACT-Europe.FR >you write:
>   > 
>   >   Yes, agreed, but I thought that it was not supported by gcc on the PA 
>   >   (typically missing some INCOMING_XXX macro things or alike).
> You're going to have to hack the compiler regardless if what solution you
> use.
> 
  OK.

> Better to hack it in the direction we'd like to go (dwarf2 unwinders) than 
> in a direction we do not want to go (compatible with HP's unwinder library).
> 
  That's fine with me. Where can I get information about what should be there,
  to deduce what's missing ? I looked at the macros and at the source for
  targets on which dwarf2 unwind is supported, but that's a pretty local view
  of the issues I think.

  How tough would it be to fill the gap, according to you ?

  Olivier
 

Re: gcc conformance to HP-PA ABI

[Jeffrey A Law]

  In message < 20000707175220.927DE5F5F6@dublin.ACT-Europe.FR >you write:
  > 
  >   Yes, agreed, but I thought that it was not supported by gcc on the PA 
  >   (typically missing some INCOMING_XXX macro things or alike).
You're going to have to hack the compiler regardless if what solution you
use.

Better to hack it in the direction we'd like to go (dwarf2 unwinders) than 
in a direction we do not want to go (compatible with HP's unwinder library).

jef

Re: gcc conformance to HP-PA ABI

[Olivier Hainque]

> 
> 
> > The idea here could be to get a support for exception handling in various
> > languages without setjmp/longjmp. Perhaps would you have other suggestions
> > to achieve this on the PA ?
> Use the dwarf2 unwinder mechanism.  It's far better for this kind of thing.
> 

  Yes, agreed, but I thought that it was not supported by gcc on the PA 
  (typically missing some INCOMING_XXX macro things or alike).

  Olivier

Re: gcc conformance to HP-PA ABI

[Richard Boylan]

On Fri, 7 Jul 100, Olivier Hainque wrote:

> Thanks again to you and Richard for your numerous comments.
>  
> > It's come up from time to time -- usually folks give up soon after they
> > start digging into the issues :(
> 
>   The idea here could be to get a support for exception handling in various
>   languages without setjmp/longjmp. Perhaps would you have other suggestions
>   to achieve this on the PA ?

I should think that the overhead of the HP unwind library would be higher
than the overhead of setjmp/longjmp.

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

Re: gcc conformance to HP-PA ABI

[Jeffrey A Law]

  In message < 20000707162455.57EF25F5F9@dublin.ACT-Europe.FR >you write:
  > Thanks again to you and Richard for your numerous comments.
  >  
  > > It's come up from time to time -- usually folks give up soon after they
  > > start digging into the issues :(
  > > 
  > > Cheers,
  > > jeffv
  > > 
  > 
  >   The idea here could be to get a support for exception handling in various
  >   languages without setjmp/longjmp. Perhaps would you have other suggestion
  > s
  >   to achieve this on the PA ?
Use the dwarf2 unwinder mechanism.  It's far better for this kind of thing.


jeff

Re: gcc conformance to HP-PA ABI

[Olivier Hainque]

Thanks again to you and Richard for your numerous comments.
 
> It's come up from time to time -- usually folks give up soon after they
> start digging into the issues :(
> 
> Cheers,
> jeffv
> 

  The idea here could be to get a support for exception handling in various
  languages without setjmp/longjmp. Perhaps would you have other suggestions
  to achieve this on the PA ?


  Best Regards,

  Olivier

Re: gcc conformance to HP-PA ABI

[Jeffrey A Law]

  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

Re: gcc conformance to HP-PA ABI

[Richard Boylan]

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

Re: gcc conformance to HP-PA ABI

[Jeffrey A Law]

  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

Re: gcc conformance to HP-PA ABI

[Olivier Hainque]

Thank you very much for your extensive comments :)

This one :

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

Indeed explains the behavior I observed on a very simple example with
respect to using -fomit-frame-pointer or not.

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

Ok.


Thanks again for all the responses I got.

Olivier
 

Re: gcc conformance to HP-PA ABI

[Richard Boylan]

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

Re: gcc conformance to HP-PA ABI

[Olivier Hainque]

> 
> 
> 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.
> 
Right, the subject of my message is incorrect with respect to this point.
By the way, all this information is described in the same HP reference
document (PA-RISC Run-time Architecture).

>   > 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.  
> 
Here is a simple example :

t.c :

int main ()
{
  U_STACK_TRACE ();
  return 0;
}

U_STACK_TRACE is one function provided by the library which prints the current
call stack. I get :

$ gcc --version              
2.95.1

$ gcc -o t t.c /usr/lib/libcl.a
$ ./t
( 0)  0x000045e0   main + 0x20  [./t]

$ gcc -fomit-frame-pointer -o t t.c /usr/lib/libcl.a 
$ ./t
( 0)  0x000045d8   main + 0x18  [./t]
( 1)  0xc0060ec4   _start + 0x8c  [/usr/lib/libc.1]
( 2)  0x00003f14   $START$ + 0x134  [./t]


> 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.
> 
As the example shows, things work fine without these directives but dont
work that well with (that is when omit-frame-pointer is off).

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

Yes, precisely. I had no doubt about this. The point is that unwinding goes 
well when *no* saving occurs (-fomit...), and unwinding does not go well when
saving *does* occur (no -fomit...).

This was exactly the reason of my question : when saving occurs, SAVE_SP flags
appear and I suppose the library uses this fact, but it seems like the way the
saving is done does not conform to the hp rules, which makes the unwinding 
process fail.

>   > 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.
> 
> This could be fixed by someone suitably interested.
> 

Oh, right. Thank you very much.


Olivier

Re: gcc conformance to HP-PA ABI

[Jeffrey A Law]

  In message < 200006301450.QAA27567@ubu.enst.fr >you write:
  > Hello,
  > 
  > 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.

This could be fixed by someone suitably interested.

  > A positive answer to the last question would mean that it will be pretty
  > hard to be able to use the library reliably.
Yes.
jeff

gcc conformance to HP-PA ABI

[Olivier Hainque]

Hello,

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

Using gcc 2.95.1 19990816 (release) on HP-UX 10.20, successful results are
only obtained when using the -fomit-frame-pointer option. 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).

Is it normal ? Did I miss something ? In case no, are there other known
cases in which the hp conventions may not be followed ?

A positive answer to the last question would mean that it will be pretty
hard to be able to use the library reliably.

Thank you very much in advance,

Olivier