From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16180 invoked by alias); 8 Jul 2003 22:43:15 -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 16173 invoked from network); 8 Jul 2003 22:43:12 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 8 Jul 2003 22:43:12 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 55E0B2B5F; Tue, 8 Jul 2003 18:43:11 -0400 (EDT) Message-ID: <3F0B48FF.3000700@redhat.com> Date: Tue, 08 Jul 2003 22:43:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "J. Johnston" Cc: gdb@sources.redhat.com Subject: Re: Problem converting ia64 to use new frame model References: <3F09F0A3.6020201@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-07/txt/msg00089.txt.bz2 First take a look through: WIP: Register doco http://sources.redhat.com/ml/gdb/2002-07/msg00202.html It's now a bit dated but the basics still apply > I am having problems converting the ia64-tdep.c file to use the new frame model. > > The main problem stems from the fact that the next frame is asked for the current > registers. When dealing with the innermost frame, the sentinel frame doesn't know how > to get all of the ia64 registers. > > In the current code, the bsp register is calculated based on the cfm and the bsp > values returned from the system. For the innermost frame, the sentinel frame just > goes to the sytem bsp value. The argument registers (32, 33, ...) need to be fetched > from a memory location based on the calculated bsp value. These registers are not accessible > via ptrace. When the sentinel frame is asked to fetch them, it ends up just grabbing > them from the regcache which returns zero. Are really two values? "bsp" which is the hardware register value you see in the frame; and (for want of a better name) "vbsp", computed from "bsp" and "cfm", which is a per-frame pointer into that the saved register space. Looking at the existing code, it appears to be: - fetching `this frame's BSP - compute the PREV BSP, but then store it in THIS->bsp so I suspect that the problem is more of the existing frame code being one frame out - it uses the PREV "bsp" when doing stuff for THIS frame. Can your register unwind code be modified to do things more along those lines? Compute the previous frame's "bsp" but then save it in this_cache? As for how to "bsp". I see it is done two ways (one for the inner most, and one for other frames) I have a feeling that the uwound "cfm" value may need adjusting. Can it be adjusted so that, for all frames, prev "bsp" can be computed using something like: this_cache -> prev_bsp = (frame_unwind_register (next, "bsp") - frame_unwind_register (next, "cfm").size-of-frame) instead of occasionally using size-of-locals (but note that I know zilch about how ia64 frames are laid out). Andrew