Re: [hpux] interesting but difficult to unwind code

["John David Anglin" <dave@hiauly1.hia.nrc.ca>]

> Here's a case that gdb cannot handle. This is from a piece of code that 
> is probably compiled by the HP compiler -- it is HP's wdb. 

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

> Interestingly, neither wdb or gdb can unwind through execute_command(). 
> The code seems to include a few interesting features:
> 
> 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.

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

> (gdb) disassemble 0xcb52f
> Dump of assembler code for function execute_command:
> 0x000cb44c <execute_command+0>: stw rp,-14(sp)
> 0x000cb450 <execute_command+4>: stw,ma r3,80(sp)
> 0x000cb454 <execute_command+8>: ldo 0(sp),r3
> 0x000cb458 <execute_command+12>:        stw r26,-a4(r3)
> 0x000cb45c <execute_command+16>:        b,l 0xcb41c <execute_command+24>,rp
> 0x000cb460 <execute_command+20>:        stw r25,-a8(r3)
> 0x000cb464 <execute_command+24>:        stw r4,-7c(r3)
> 0x000cb468 <execute_command+28>:        ldo 1(ret0),ret1
> 0x000cb46c <execute_command+32>:        stw r5,-78(r3)
> 0x000cb470 <execute_command+36>:        stw r6,-74(r3)
> 0x000cb474 <execute_command+40>:        ldw -10(sp),r26
> 0x000cb478 <execute_command+44>:        ldw -4(sp),r19
> 0x000cb47c <execute_command+48>:        addi 3f,ret1,r1
> 0x000cb480 <execute_command+52>:        depwi 0,31,6,r1
> 0x000cb484 <execute_command+56>:        ldi 38,rp
> 0x000cb488 <execute_command+60>:        sub sp,rp,ret1
> 0x000cb48c <execute_command+64>:        add sp,r1,sp
> 0x000cb490 <execute_command+68>:        stw r19,-4(sp)
> 0x000cb494 <execute_command+72>:        stw r26,-10(sp)

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.

> 0x000cb498 <execute_command+76>:        ldw -a4(r3),r25
> 0x000cb49c <execute_command+80>:        ldo 0(ret1),r26
> 0x000cb4a0 <execute_command+84>:        b,l 0xcb424 <execute_command+32>,rp
> 
> (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.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)