From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-23665-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 22603 invoked by alias); 9 Dec 2005 00:08:54 -0000
Received: (qmail 22452 invoked by uid 22791); 9 Dec 2005 00:08:51 -0000
X-Spam-Check-By: sourceware.org
Received: from ip127.bb146.pacific.net.hk (HELO mailhub.stlglobal.com) (202.64.146.127)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 09 Dec 2005 00:08:47 +0000
Received: from 236.193.17.210.dyn.pacific.net.hk ([210.17.193.236] helo=[192.168.1.10]) 	by mailhub.stlglobal.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) 	(Exim 4.50) 	id 1EkVnp-0006kU-6c; Fri, 09 Dec 2005 08:07:57 +0800
Message-ID: <4398CAEE.8030409@tausq.org>
Date: Fri, 09 Dec 2005 00:08:00 -0000
From: Randolph Chung <randolph@tausq.org>
User-Agent: Debian Thunderbird 1.0.2 (X11/20050331)
MIME-Version: 1.0
To: John David Anglin <dave@hiauly1.hia.nrc.ca>,   Joel Brobecker <brobecker@adacore.com>,   gdb@sources.redhat.com
Subject: [hpux] interesting but difficult to unwind code
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2005-12/txt/msg00093.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. 
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()

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


(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)
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
         Region_description = 0x0
         Entry_FR = 0x0
         Entry_GR = 0x4
         Total_frame_size = 0x10

I'm not sure if this is really ABI compliant.....
Any suggestions on what we can do here?

randolph