From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3536 invoked by alias); 12 May 2002 03:52:28 -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 3528 invoked from network); 12 May 2002 03:52:27 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 12 May 2002 03:52:27 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 1FDBA3E07; Sat, 11 May 2002 23:52:34 -0400 (EDT) Message-ID: <3CDDE701.90603@cygnus.com> Date: Sat, 11 May 2002 20:52:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0rc1) Gecko/20020429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: davidm@hpl.hp.com Cc: gdb-patches@sources.redhat.com Subject: Re: new gdb arch routine FRAME_UNCHANGED References: <200205110023.g4B0NVCF004832@napali.hpl.hp.com> <3CDC6E2F.9020702@cygnus.com> <15580.31869.406085.760707@napali.hpl.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-05/txt/msg00419.txt.bz2 > On Fri, 10 May 2002 21:04:47 -0400, Andrew Cagney said: > > > Andrew> Is the patch available somewhere? > > Not online, but if you want me to, I'm happy to send the complete > patch to gdb-patches so you can see where I'm going (or thought I was > going... ;-). Tossing out the work-in-progress will probably be useful - KevinB (ia64 maintainer) would at very likely be interested in what is comming his way :-) (I should also double check what HP's Assignement status is.) > Andrew> When you say unwind library support do you mean dwarf2cfi or > Andrew> something else? From memory CFI identifies a frame using > Andrew> CFA and PC, I'm wondering how things work here. > > The ia64 conventions come with their own unwind info. The conventions > do not define a unique address/identifier for each frame. > Andrew> cf: > Andrew> http://sources.redhat.com/ml/gdb-patches/2002-04/msg00749.html > Andrew> There is code through out GDB that relies on being able to > Andrew> re-find a frame in the frame chain. The code typically > Andrew> relies on just the frame address (oops). The referenced > Andrew> patch changes it to use frame/pc. If I understand what > Andrew> you're saying correctly, still more information will need to > Andrew> be saved? > > Yes, this is an issue I was wondering about, too. My goal was fairly > limited though: I just wanted to change gdb/ia64 to an unwind-info > based implementation that works at least as well as the old version of > gdb/ia64. I didn't look into this specific issue. > It sounds like for ia64 we would need to add a another field to struct > frame_id to track the register stack address of a frame. Otherwise, a > recursive function that only uses the register stack would lead to a > series of indistinguishable frames (a simple recursive factorial would > do that). Yep. Hmm, is it possible to re-enter a function without changing the register stack pointer? If it isn't then the register stack pointer could be used for frame->frame. > Is the idea to treat frame_id as an opaque structure? If so, I could > add a routine to the unwind library API to obtain a unique frame-id > for a given frame. That way, the ia64 issue could be hidden behind > the API. The value can't be really opaque. GUI code and MI are easier if they don't have to worry about malloc/free (frame_id being a lightweight) and MI needs to be able to pass the contents back to clients. However, gdbarch methods to fill in and compare frame_id's could certainly be added. Andrew