From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30787 invoked by alias); 19 Feb 2003 16:46:56 -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 30772 invoked from network); 19 Feb 2003 16:46:55 -0000 Received: from unknown (HELO localhost.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 19 Feb 2003 16:46:55 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id C27AC2E96; Wed, 19 Feb 2003 11:51:40 -0500 (EST) Message-ID: <3E53B61C.2050807@redhat.com> Date: Wed, 19 Feb 2003 16:46:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.0.2) Gecko/20030217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: GDB Patches Subject: Re: [patch/rfc] Add a sentinel frame References: <3E305670.3020700@redhat.com> <3E48378E.6090007@suse.cz> <3E492953.8010001@redhat.com> <3E52173B.1030800@suse.cz> <3E538770.6070209@redhat.com> <20030219140441.GA20537@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-02/txt/msg00409.txt.bz2 > On Wed, Feb 19, 2003 at 08:32:32AM -0500, Andrew Cagney wrote: > >> So I think it is one of these tests going awall: >> >> if (next_frame->level >= 0 >> && !backtrace_below_main >> && inside_main_func (get_frame_pc (next_frame))) >> /* Don't unwind past main(), bug always unwind the sentinel frame. >> Note, this is done _before_ the frame has been marked as >> previously unwound. That way if the user later decides to >> allow unwinds past main(), that just happens. */ >> return NULL; >> >> /* If we're inside the entry file, it isn't valid. */ >> /* NOTE: drow/2002-12-25: should there be a way to disable this >> check? It assumes a single small entry file, and the way some >> debug readers (e.g. dbxread) figure out which object is the >> entry file is somewhat hokey. */ >> /* NOTE: cagney/2003-01-10: If there is a way of disabling this test >> then it should probably be moved to before the ->prev_p test, >> above. */ >> if (inside_entry_file (get_frame_pc (next_frame))) >> return NULL; >> >> The second looks worrying (the dummy frame breakpoint lives in the entry >> file ...). Perhaphs something like: >> >> if (dummy_frame_p (get_frame_pc (next_frame) != NULL >> && inside_entry_file (get_frame_pc (next_frame)) >> return NULL; > > > Hrm, shouldn't we have already detected the dummy frame at this point? No. GDB is trying to perform: pop_frame (get_current_frame()) with the assumption that it has a dummy frame and get_current_frame() will return it. > That's what happens on i386 IIRC... Chance has it inside_entry_file(entry-point) returns false. Knowing that function, I'd not be suprized. The `bug' is an unexpected interaction between get_prev_frame's end-of-frame test and the change to unwind from the sentinel frame. Previously the end-of-frame test wasn't applied to the current frame. Andrew