From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32337 invoked by alias); 17 Feb 2003 15:37:29 -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 32330 invoked from network); 17 Feb 2003 15:37:28 -0000 Received: from unknown (HELO localhost.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 17 Feb 2003 15:37:28 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 906753CE5; Mon, 17 Feb 2003 10:37:30 -0500 (EST) Message-ID: <3E5101BA.5000504@redhat.com> Date: Mon, 17 Feb 2003 15:37:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.1) Gecko/20021211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz , Kevin Buettner Cc: gdb@sources.redhat.com Subject: Re: frame_register_unwind(): "frame != NULL" assertion failure References: <1030213212349.ZM2427@localhost.localdomain> <20030213212904.GA14115@nevyn.them.org> <1030213213526.ZM2489@localhost.localdomain> <1030213214819.ZM2541@localhost.localdomain> <1030213232706.ZM8198@localhost.localdomain> <3E4D042F.3060102@redhat.com> <20030214151451.GC30416@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-02/txt/msg00258.txt.bz2 > On Feb 14, 10:14am, Daniel Jacobowitz wrote: > > >> > However, can you please first investigate modifying the start of >> > mips_init_extra_frame_info() where it does: >> > >> > proc_desc = get_next_frame (fci) ? ..... >> > >> > to, when get_next_frame(fci) is null, call: >> > >> > find_proc_desc (get_frame_pc (fci), fci, 1); >> > >> > that is the current, and not prev frame. > >> >> I'm pretty sure that won't work Hmm, yes. I took the name `read_next_frame_reg()' at face value :-( That leaves us with: > - we're initializing the saved regs for >> fci right now, and find_proc_desc wants a frame to read registers out >> of. BTW. This problem is going away. New targets should no longer need to do all those get_next_frame(FCI) calls since the new tdep methods have that next frame passed in. This is also why the comment: + /* Note: kevinb/2003-02-13: This is a hack. The problem is that + get_next_frame() can return NULL when it really ought to be + returning the sentinel frame. So, when we detect frame == NULL, + just use the sentinel frame instead. + FIXME: Remove this hack once get_next_frame() has been fixed + to never return NULL. */ is misleading. get_next_frame(current_frame), by definition, is NULL. The new tdep code uses OLD_NEXT_FRAME->unwind() instead of relying on: HALF_INITIALIZED_NEW_PREV_FRAME->next->unwind() (the sentinal frame unwind still needs to be cleaned up). The one fly in the ointment is that the sentinel frame unwinder is still hardwired. Anyway, Kevin, /* 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. Andrew