From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13459 invoked by alias); 18 Feb 2003 02:39: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 13407 invoked from network); 18 Feb 2003 02:39:14 -0000 Received: from unknown (HELO localhost.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 18 Feb 2003 02:39:14 -0000 Received: by localhost.redhat.com (Postfix, from userid 1008) id CC1B63CF1; Mon, 17 Feb 2003 20:54:13 -0500 (EST) Subject: Re: frame_register_unwind(): "frame != NULL" assertion failure In-Reply-To: <1030217232113.ZM570@localhost.localdomain> "from Kevin Buettner at Feb 17, 2003 04:21:14 pm" To: Kevin Buettner Date: Tue, 18 Feb 2003 02:39:00 -0000 Cc: Andrew Cagney , Daniel Jacobowitz , gdb@sources.redhat.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <20030218015413.CC1B63CF1@localhost.redhat.com> From: ac131313@redhat.com (Andrew Cagney) X-SW-Source: 2003-02/txt/msg00294.txt.bz2 > On Feb 17, 4:37pm, Andrew Cagney wrote: > > > /* Use proc_desc calculated in frame_chain */ > > proc_desc = > > get_next_frame (fci) > > ? cached_proc_desc > > : find_proc_desc (get_frame_pc (fci), get_next_frame (fci), 1); > > > > can you please change the above to be: > > > > : find_proc_desc (get_frame_pc (fci), NULL, 1); > > > > (with a comment) and modify read_next_frame_reg() to, when NULL, pull a > > value from the register cache. e.g., The mips should be updated to use the new frame unwind mechanisms and, as part of this, implement a custom sentinel frame unwinder (which would be passed the sentinal frame as a parameter). The MIPS specific sentinel frame unwind code could then call find_proc_desc() with the sentinel frame making all the frame==NULL tests redundant. In the mean time, this call to find_proc_desc() passes in an explicit (rather than implicit) NULL (by definition current_frame-> == NULL). This way the task of tracking down if/where find_proc_desc is called with a NULL frame is made much much easier. > I will do this, but I really do not think it's the best solution. (If > we're going to be checking for frame == NULL, then why did you introduce > sentinel frames in the first place?) It is part of the hack. The `correct fix' (rewrite MIPS to use the unwind mechanism) would eliminate that call. Andrew