From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15031 invoked by alias); 1 Jul 2003 01:20:37 -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 15023 invoked from network); 1 Jul 2003 01:20:35 -0000 Received: from unknown (HELO hydra.ubicom.com) (4.20.168.98) by sources.redhat.com with SMTP; 1 Jul 2003 01:20:35 -0000 Received: FROM fenway.scenix.com BY hydra.ubicom.com ; Mon Jun 30 18:18:33 2003 -0700 Received: from nkelseyxp (NKELSEY-XP [192.168.1.187]) by fenway.scenix.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id N6WLRD11; Mon, 30 Jun 2003 18:18:31 -0700 Message-ID: <09a601c33f6e$b05a3480$0a02a8c0@scenix.com> Reply-To: "Jafa" From: "Jafa" To: Subject: Frame handling Date: Tue, 01 Jul 2003 01:20:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-SW-Source: 2003-07/txt/msg00003.txt.bz2 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. frame_base_set_default also sets the unwind options... type - always NORMAL_FRAME? 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? 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. frame_unwind_append_predicate (gdbarch, d10v_frame_p) - this seams to register the same unwind options as above? I think this makes sense but I would appreciate a sanity check :-) Thanks Nick Nick Kelsey Senior Software Engineer Ubicom