From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22050 invoked by alias); 13 May 2002 22:46:08 -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 22034 invoked from network); 13 May 2002 22:46:07 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 13 May 2002 22:46:07 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 7DB543E16; Mon, 13 May 2002 18:46:16 -0400 (EDT) Message-ID: <3CE04238.3060102@cygnus.com> Date: Mon, 13 May 2002 15:46: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> <3CDDE701.90603@cygnus.com> <15584.11515.164115.822423@napali.hpl.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-05/txt/msg00504.txt.bz2 > 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. Ah, ok. I guess `struct { CORE_ADDR x[3]; }'. If someone finds they need more entries then we can just keep making it bigger. Trailing unused entries are zero. The reason for advising against pointers or variable size struct is that these objects are not well managed in terms of malloc/delete. The ptid is another example of the same thing of the same thing - no need to worry about memory leaks. > 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? Some existing code wants to compare based on just frame. See stack.c:parse_frame_specification. Stop on first trailing zero? Also, code wants to determine which code is more INNER_THAN(). With two stacks, that starts to get really weird! Andrew