From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2883 invoked by alias); 17 Apr 2004 16:54:56 -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 2876 invoked from network); 17 Apr 2004 16:54:55 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 17 Apr 2004 16:54:55 -0000 Received: from drow by nevyn.them.org with local (Exim 4.31 #1 (Debian)) id 1BEt5j-0003wW-6A; Sat, 17 Apr 2004 12:54:55 -0400 Date: Sat, 17 Apr 2004 16:54:00 -0000 From: Daniel Jacobowitz To: Randolph Chung Cc: gdb-patches@sources.redhat.com Subject: Re: [patch] Fix unwind handling for hppa Message-ID: <20040417165455.GA14387@nevyn.them.org> Mail-Followup-To: Randolph Chung , gdb-patches@sources.redhat.com References: <20040417080536.GB17842@tausq.org> <20040417163525.GA3521@nevyn.them.org> <20040417172027.GD17842@tausq.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040417172027.GD17842@tausq.org> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-04/txt/msg00393.txt.bz2 On Sat, Apr 17, 2004 at 10:20:27AM -0700, Randolph Chung wrote: > > > + if (frame_relative_level (next_frame) >= 0 || > > > + frame_pc_unwind (next_frame) >= > > > + hppa_skip_prologue (frame_func_unwind (next_frame))) > > > > - your formatting is wrong; operators always come at the beginning > > of the line. > > ok, i have to go and read the coding style doc some more since it is > very different from what i'm used to :) > > > - 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. > > mmmm, ok. so if i just do: > > if (frame_pc_unwind (next_frame) > >= hppa_skip_prologue (frame_func_unwind (next_frame))) > > then it's ok? or is there a more efficient/correct mechanism to get to > this info? Beats me. I guess that might work. At that point you're more or less running the prologue analyzer despite having unwind data; I'm not sure how I feel about that. But it does seem pragmatically useful. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer