From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11845 invoked by alias); 1 Jul 2003 03:42:36 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 11838 invoked from network); 1 Jul 2003 03:42:35 -0000 Received: from unknown (HELO crack.them.org) (146.82.138.56) by sources.redhat.com with SMTP; 1 Jul 2003 03:42:35 -0000 Received: from dsl093-172-017.pit1.dsl.speakeasy.net ([66.93.172.17] helo=nevyn.them.org ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 19XC3I-0006wy-00; Mon, 30 Jun 2003 22:43:32 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19XC2K-0000ud-00; Mon, 30 Jun 2003 23:42:32 -0400 Date: Tue, 01 Jul 2003 03:42:00 -0000 From: Daniel Jacobowitz To: Jafa Cc: gdb@sources.redhat.com Subject: Re: Frame handling Message-ID: <20030701034232.GB3434@nevyn.them.org> Mail-Followup-To: Jafa , gdb@sources.redhat.com References: <09a601c33f6e$b05a3480$0a02a8c0@scenix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09a601c33f6e$b05a3480$0a02a8c0@scenix.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-07/txt/msg00005.txt.bz2 On Mon, Jun 30, 2003 at 06:18:33PM -0700, Jafa wrote: > Hi all, > > I am bringing the ip2k port back in sync with the trunk and I need to check > my (limited) understanding of the new scheme... > > This email is mostly a ramble about my understanding of the new frame > handling that I would like a sanity check on. > > frame_base_set_default (gdbarch, &avr_frame_base) registers a set of > function handlers: > this_base - given a frame, figure out the base address of the caller frame > (caller's FP)... usually this means doing some analysis to figure everything > out about the frame and populating the port-specific cache for this new > frame. > this_locals - given a frame, figure out the address of the local variables > of the callers frame (usually caller's FP as debug info already allows for > the offset). > this_args - given a frame, figure out the address of the args passed to the > callers frame (usually caller's FP as debug info already allows for the > offset). > > Port specific implementation... The first time one of these functions is > called the port-specific cache will be a NULL pointer... the code should > allocate memory to hold the useful frame variables and figure out the frame > information. Subsequent calls will receive the cache back and can return the > values from the cache. You're good so far. > frame_base_set_default also sets the unwind options... No, it doesn't. That unwind member is used for comparison purposes only. See the "Sneaky" comment in get_frame_base_address, and all of "frame-unwind.h". Esp. frame_unwind_append_predicate. > type - always NORMAL_FRAME? For a target's unwinders, probably. > this_id - Given a frame, return a unique identifier for the caller's frame > based on the caller's frame base address and the calling functions entry > point. > prev_register - Given a frame, return the value of a specified register as > it was on entry to this function (registers that are known to be saved on > the stack) > > Question - what registers is gdb expecting prev_register to give reasonable > results for? Just PC? Or SP and FP as well? As many as possible. This _completely_ replaces all other unwinding, for instance frame_chain and the extra_info/saved_registers data. Might want to take a look at the ARM conversion I just posted; I don't promise it's right... > Question - reading through this again I think the goal of call these > functions is to work with the current frame and the function get passed the > child frame so they can do a backtrace if it hasn't already been done... why > not call a function to do a 1 level backtrace and then eliminate the > next_frame parameter? It would recduce confusion and most ports will have an > internal unwind function anyway. Because it doesn't make much difference, I think. The key is that the info generated when doing the backtrace is target specific, and opaque. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer