From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32608 invoked by alias); 9 Dec 2005 03:33:53 -0000 Received: (qmail 32601 invoked by uid 22791); 9 Dec 2005 03:33:52 -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 03:33:50 +0000 Received: from rccomp.stlglobal.com ([192.168.100.200]) by mailhub.stlglobal.com with esmtp (Exim 4.50) id 1EkZ0V-0007uU-Dz; Fri, 09 Dec 2005 11:33:15 +0800 Message-ID: <4398FB10.1050307@tausq.org> Date: Fri, 09 Dec 2005 03:33:00 -0000 From: Randolph Chung User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: John David Anglin CC: brobecker@adacore.com, gdb@sources.redhat.com Subject: Re: [hpux] interesting but difficult to unwind code References: <200512090044.jB90in3E017441@hiauly1.hia.nrc.ca> In-Reply-To: <200512090044.jB90in3E017441@hiauly1.hia.nrc.ca> Content-Type: text/plain; charset=ISO-8859-1 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/msg00095.txt.bz2 > 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 >> region_end = 0xcb798 >> 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/