From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4020 invoked by alias); 6 Dec 2004 23:37:38 -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 3995 invoked from network); 6 Dec 2004 23:37:35 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 6 Dec 2004 23:37:35 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1CbSQ4-0008SW-LC; Mon, 06 Dec 2004 18:37:28 -0500 Date: Mon, 06 Dec 2004 23:42:00 -0000 From: Daniel Jacobowitz To: Randolph Chung Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC/hppa] Change handling of stubs in the return path Message-ID: <20041206233728.GA32454@nevyn.them.org> Mail-Followup-To: Randolph Chung , gdb-patches@sources.redhat.com References: <20041206223712.GQ6359@tausq.org> <20041206230631.GB31381@nevyn.them.org> <20041206232723.GS6359@tausq.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041206232723.GS6359@tausq.org> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-12/txt/msg00179.txt.bz2 On Mon, Dec 06, 2004 at 03:27:23PM -0800, Randolph Chung wrote: > > Does this work OK when single stepping out of something, i.e. back into > > a stub? > > when you step out of a function that was called with a stub, you end up > back at the caller, not the stub. is that what you mean? (when we step > into the stub, gdb detects that it is in a solib return trampoline and > runs the inferior until it is out of the trampoline). that part is not > really affected by this patch though. When you step one instruction out of the function, you go from "frame A, called by frame B" to "frame C, called by frame B". Does GDB get confused by this? Try using "step"; it may decide that frame C was called by frame A, and resume. I guess that doesn't matter. What usually happens in this case is GDB loses control; but if it does, it will just hit the dummy frame breakpoint, so who cares? > > > > +static void > > > +hppa_hpux_unwind_adjust_stub(struct frame_info *next_frame, CORE_ADDR base, > > > + struct trad_frame_saved_reg *saved_regs) > > > > Formatting ;-) > > sorry, the original version is ok, but i did some manual editting of the > file with vim that had expandtab set... I meant the missing space after _stub. -- Daniel Jacobowitz