Re: [hpux] interesting but difficult to unwind code

[Randolph Chung <randolph@tausq.org>]

> No, this code has been compiled by GCC.  The save of the frame
> pointer at the incomming stack pointer address is the clue.  SAVE_SP
> should be set to indicate this.  This should allow unwinding
> through this function...

hrm, is there a way to verify this other than the above? The fact that
the "args_stored" flag is set in the unwind record is also a bit
surprising, as (afaict) gcc doesn't emit this flag.

I downloaded this wdb binary from HP's website and their documentation
also seems to suggest that it is compiled with HP compilers.

>> 1) it has a branch right in the middle of the prologue at +16. This is a 
>> call to strlen()
> 
> Interesting.  It looks ok from a functional standpoint.

Yes, but I've never seen gcc do this.... does it?

>> 2) It contains a stack adjustment beyond what is marked in the unwind 
>> info. This is probably due to alloca(). Note that there is nothing in 
>> the unwind data that indicates this. The line of code in wdb that 
>> generates this is probably:
>>
>>   save_line = (char *) alloca (strlen (p) + 1);
> 
> GCC has never recorded alloca adjustments.  However, SAVE_SP will
> be set in any frame using alloca.

Right.

> Note copy of info stored at -4 and -10 in the frame marker.  This
> is mandated by the ABI but unfortunately psp isn't required to be
> saved in the frame marker.  So it's not a whole lot of use.  Signal
> frames are the only ones that I know save the psp for sure.  In
> any case, r3 contains the previous stack pointer.

The problem is that currently, absent some indication from the unwind
data that a frame pointer is present (e.g. Save_SP), we do not use the
saved frame pointer to do unwinding. This can probably be enhanced by
teaching gdb more about common prologue sequences that actually store
the psp into r3. Perhaps this is another argument for Joel's proposal to
do more detailed prologue analysis.

>> (gdb) maintenance print unwind execute_command
>> unwind_table_entry (0x40286424):
>>          region_start = 0xcb44c <execute_command>
>>          region_end = 0xcb798 <execute_command+844>
>>          flags = Args_stored Save_RP
> 
> I don't understand why you don't see SAVE_SP in the flags.

Yes, very odd....

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/