From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 399 invoked by alias); 12 May 2006 06:21:03 -0000 Received: (qmail 376 invoked by uid 22791); 12 May 2006 06:21:00 -0000 X-Spam-Check-By: sourceware.org Received: from intranet.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.6) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 12 May 2006 06:20:05 +0000 Received: (qmail 29457 invoked from network); 12 May 2006 06:20:04 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 12 May 2006 06:20:04 -0000 To: gdb-patches@sourceware.org Subject: Re: [RFC] Move the frame zero PC check earlier References: <20060510180312.GA12606@nevyn.them.org> <20060511223208.GA19492@nevyn.them.org> From: Jim Blandy Date: Fri, 12 May 2006 06:21:00 -0000 In-Reply-To: <20060511223208.GA19492@nevyn.them.org> (Daniel Jacobowitz's message of "Thu, 11 May 2006 18:32:08 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00230.txt.bz2 Daniel Jacobowitz writes: > On Thu, May 11, 2006 at 03:24:31PM -0700, Jim Blandy wrote: >> >> It looks good to me. I'm just curious why we even bother looking up >> the frame type for the older frame whose PC is zero. (I understand >> this test is inherited from the existing code.) > > You've gotta. It looks like this: > > #0 somefunc () > #1 > #2 0x00000000 in Nothing At All > #3 function_which_calls_its_arg (arg = (void (*)()) 0x00000000) > #4 main () > > There was a check for this at some point in the distant past - I > believe it was committed, not just proposed - which didn't do this. > Ergo signull.exp. > > Er... wait a second! You're talking about a different frame than I am, > aren't you? Do you mean this? > > + if (prev_frame->level > 0 > + && get_frame_type (this_frame) == NORMAL_FRAME > + && get_frame_pc (prev_frame) == 0) I think so. Using the backtrace above as an example, I understood why we need to know frame #1's type, but I didn't see the point in checking frame #2's type. But I think I do now. If CALL_DUMMY_LOCATION is AT_ENTRY_POINT, and the entry point is at address zero, then the test as written above would truncate backtraces at dummy frames.