From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27646 invoked by alias); 20 Aug 2006 14:33:17 -0000 Received: (qmail 27637 invoked by uid 22791); 20 Aug 2006 14:33:17 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 20 Aug 2006 14:33:16 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id k7KEWemT025278; Sun, 20 Aug 2006 16:32:41 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.6/8.13.6) with ESMTP id k7KEWecn023988; Sun, 20 Aug 2006 16:32:40 +0200 (CEST) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.6/8.13.6/Submit) id k7KEWeKR010677; Sun, 20 Aug 2006 16:32:40 +0200 (CEST) Date: Sun, 20 Aug 2006 16:48:00 -0000 Message-Id: <200608201432.k7KEWeKR010677@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: gdb-patches@sourceware.org In-reply-to: <20060819155654.GB25238@nevyn.them.org> (message from Daniel Jacobowitz on Sat, 19 Aug 2006 11:56:54 -0400) Subject: Re: [rfc, frame] Move the corrupt frame checks earlier References: <20060819155654.GB25238@nevyn.them.org> 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-08/txt/msg00139.txt.bz2 > Date: Sat, 19 Aug 2006 11:56:54 -0400 > From: Daniel Jacobowitz > > This patch is a follow-on to the unwind_stop_reason patch, although not > actually dependent. It moves the frame-went-inner and frame-same-ID > checks earlier in the backtrace process. Although they move down > in the function, they also check PREV rather than THIS. > > The benefit of doing this is that we display the stop reason before, > rather than after, the frame we've decided is corrupt. For instance, > suppose we have two frames with the same ID. That means they have the > same CFA and the same function. In other words, the same stack frame. > So the second backtrace entry will be a duplicate of the first. There's > no added value in displaying it, and logically it doesn't need to exist > on the frame chain. Sorry it's not clear to me what exactly the effect is. Does it make frames disappear that are there now? I wouldn't like that, since it the past I clearly remember getting useful information out of the last frame printed in a bad backtrace. Perhaps you can give an example of the old & new behaviour? Mark