From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15887 invoked by alias); 13 May 2002 21:15:47 -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 15874 invoked from network); 13 May 2002 21:15:44 -0000 Received: from unknown (HELO deimos.hpl.hp.com) (192.6.19.190) by sources.redhat.com with SMTP; 13 May 2002 21:15:44 -0000 Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33]) by deimos.hpl.hp.com (8.9.3 (PHNE_24419)/HPL-PA Relay) with ESMTP id OAA21992; Mon, 13 May 2002 14:15:40 -0700 (PDT) Received: from napali.hpl.hp.com (napali.hpl.hp.com [15.4.89.123]) by hplms2.hpl.hp.com (8.10.2/8.10.2 HPL-PA Hub) with ESMTP id g4DLFd214933; Mon, 13 May 2002 14:15:39 -0700 (PDT) Received: from napali.hpl.hp.com (localhost [127.0.0.1]) by napali.hpl.hp.com (8.12.2/8.12.2/Debian -5) with ESMTP id g4DLFdeM023001; Mon, 13 May 2002 14:15:39 -0700 Received: (from davidm@localhost) by napali.hpl.hp.com (8.12.2/8.12.2/Debian -5) id g4DLFdsd022997; Mon, 13 May 2002 14:15:39 -0700 From: David Mosberger MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15584.11515.164115.822423@napali.hpl.hp.com> Date: Mon, 13 May 2002 14:15:00 -0000 To: Andrew Cagney Cc: davidm@hpl.hp.com, gdb-patches@sources.redhat.com Subject: Re: new gdb arch routine FRAME_UNCHANGED In-Reply-To: <3CDDE701.90603@cygnus.com> References: <200205110023.g4B0NVCF004832@napali.hpl.hp.com> <3CDC6E2F.9020702@cygnus.com> <15580.31869.406085.760707@napali.hpl.hp.com> <3CDDE701.90603@cygnus.com> Reply-To: davidm@hpl.hp.com X-URL: http://www.hpl.hp.com/personal/David_Mosberger/ X-SW-Source: 2002-05/txt/msg00497.txt.bz2 >>>>> On Sat, 11 May 2002 23:52:33 -0400, Andrew Cagney said: Andrew> Tossing out the work-in-progress will probably be useful - Andrew> KevinB (ia64 maintainer) would at very likely be interested Andrew> in what is comming his way :-) Oh, I already discussed the complete patch with KevinB. Andrew> Hmm, is it possible to re-enter a function without changing Andrew> the register stack pointer? Yes. Andrew> If it isn't then the register Andrew> stack pointer could be used for frame->frame. That doesn't work. I think you might be able to get away with using the memory stack pointer *OR* the register stack pointer as a unique id for each frame, but that seems rather ugly and I suspect there are cases where you might run into ambiguities. >> 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. Andrew> The value can't be really opaque. GUI code and MI are Andrew> easier if they don't have to worry about malloc/free Andrew> (frame_id being a lightweight) and MI needs to be able to Andrew> pass the contents back to clients. Oh, by "opaque" I didn't mean a "void *". Just an object of a fixed size with an undefined structure. I agree that it's preferable to be able to declare automatic variables of this type. I was thinking of having an array of "void *" inside an struct, with the array size being architecture-specific. Andrew> However, gdbarch methods to fill in and compare frame_id's Andrew> could certainly be added. OK, that would probably do it. Do you see any need to calculate a hash or is comparison for equality sufficient? --david