From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24681 invoked by alias); 17 Apr 2004 16:35:28 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 24673 invoked from network); 17 Apr 2004 16:35:27 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 17 Apr 2004 16:35:27 -0000 Received: from drow by nevyn.them.org with local (Exim 4.31 #1 (Debian)) id 1BEsmr-0001pL-Ez; Sat, 17 Apr 2004 12:35:25 -0400 Date: Sat, 17 Apr 2004 16:35:00 -0000 From: Daniel Jacobowitz To: Randolph Chung Cc: gdb-patches@sources.redhat.com Subject: Re: [patch] Fix unwind handling for hppa Message-ID: <20040417163525.GA3521@nevyn.them.org> Mail-Followup-To: Randolph Chung , gdb-patches@sources.redhat.com References: <20040417080536.GB17842@tausq.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040417080536.GB17842@tausq.org> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-04/txt/msg00391.txt.bz2 On Sat, Apr 17, 2004 at 01:05:36AM -0700, Randolph Chung wrote: > Frame unwinding on hppa was broken when the frame unwind started at a > location before the current frame is created (as noted by the comment > below). This patch fixes it and brings the failure count on > hppa2.0w-hp-hpux11 down from 1000 to 668, and on hppa-linux from 2700+ > to 1214. still some ways to go :) > > Many thanks to Dan for patiently answering my questions. > > ok to commit? Nope, a couple of things: > + if (frame_relative_level (next_frame) >= 0 || > + frame_pc_unwind (next_frame) >= > + hppa_skip_prologue (frame_func_unwind (next_frame))) Andrew and I just had this same discussion with MIPS. Problems with this line include: - your formatting is wrong; operators always come at the beginning of the line. - Checking the frame level is wrong. It's wrong both in practice and in principle: in practice, the next frame could be a dummy frame or a signal frame. There's a test case in the testsuite which covers this. In principle, the point is to unwind without magic knowledge of the next frame. At least, that's what Andrew insists. I don't think that I agree; I think the knowledge of whether we got from this frame to the next frame via a call is a legitimate piece of information to use during unwinding and can save a lot of inefficient code analysis. But that's unsettled. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer