From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5288 invoked by alias); 9 Dec 2005 00:44:56 -0000 Received: (qmail 5281 invoked by uid 22791); 9 Dec 2005 00:44:55 -0000 X-Spam-Check-By: sourceware.org Received: from hiauly1.hia.nrc.ca (HELO hiauly1.hia.nrc.ca) (132.246.100.193) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 09 Dec 2005 00:44:53 +0000 Received: from hiauly1.hia.nrc.ca (hiauly1.hia.nrc.ca [127.0.0.1] (may be forged)) by hiauly1.hia.nrc.ca (8.12.9-20030917/8.12.9) with ESMTP id jB90inqO017442; Thu, 8 Dec 2005 19:44:50 -0500 (EST) Received: (from dave@localhost) by hiauly1.hia.nrc.ca (8.12.9-20030917/8.12.9/Submit) id jB90in3E017441; Thu, 8 Dec 2005 19:44:49 -0500 (EST) Message-Id: <200512090044.jB90in3E017441@hiauly1.hia.nrc.ca> Subject: Re: [hpux] interesting but difficult to unwind code To: randolph@tausq.org (Randolph Chung) Date: Fri, 09 Dec 2005 00:44:00 -0000 From: "John David Anglin" Cc: brobecker@adacore.com, gdb@sources.redhat.com In-Reply-To: <4398CAEE.8030409@tausq.org> from "Randolph Chung" at Dec 9, 2005 08:08:14 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-12/txt/msg00094.txt.bz2 > 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 : stw rp,-14(sp) > 0x000cb450 : stw,ma r3,80(sp) > 0x000cb454 : ldo 0(sp),r3 > 0x000cb458 : stw r26,-a4(r3) > 0x000cb45c : b,l 0xcb41c ,rp > 0x000cb460 : stw r25,-a8(r3) > 0x000cb464 : stw r4,-7c(r3) > 0x000cb468 : ldo 1(ret0),ret1 > 0x000cb46c : stw r5,-78(r3) > 0x000cb470 : stw r6,-74(r3) > 0x000cb474 : ldw -10(sp),r26 > 0x000cb478 : ldw -4(sp),r19 > 0x000cb47c : addi 3f,ret1,r1 > 0x000cb480 : depwi 0,31,6,r1 > 0x000cb484 : ldi 38,rp > 0x000cb488 : sub sp,rp,ret1 > 0x000cb48c : add sp,r1,sp > 0x000cb490 : stw r19,-4(sp) > 0x000cb494 : 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 : ldw -a4(r3),r25 > 0x000cb49c : ldo 0(ret1),r26 > 0x000cb4a0 : b,l 0xcb424 ,rp > > (gdb) maintenance print unwind execute_command > unwind_table_entry (0x40286424): > region_start = 0xcb44c > region_end = 0xcb798 > 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)