This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: [hpux] interesting but difficult to unwind code
- From: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- To: randolph at tausq dot org (Randolph Chung)
- Cc: brobecker at adacore dot com, gdb at sources dot redhat dot com
- Date: Thu, 8 Dec 2005 19:44:49 -0500 (EST)
- Subject: Re: [hpux] interesting but difficult to unwind code
> 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)