Re: gcc conformance to HP-PA ABI

[Olivier Hainque <hainque at inf dot enst dot fr>]

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