From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24766 invoked by alias); 28 Mar 2004 22:31:07 -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 24757 invoked from network); 28 Mar 2004 22:31:05 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 28 Mar 2004 22:31:05 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 021A42B9C; Sun, 28 Mar 2004 17:31:07 -0500 (EST) Message-ID: <4067522B.2030803@gnu.org> Date: Sun, 28 Mar 2004 22:31:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Jim Blandy Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/rfc] frame_id_unwind References: <4062EBF9.7040908@gnu.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00707.txt.bz2 >>> Can anyone think of a testcase? > However, 'backtrace' won't work right in such a program; if that's > fixed, then this test won't be much of a test any more. Hmm. Hence the problem, other cases tend to end in a similar dead end. > A thought on the underlying issues: > > It seems to me that there are two distinct things being mixed together > here: One returns a subset of the other. > Wouldn't things work better if we moved the decision about where to > stop displaying the stack into user interface code (I don't know if > there's any place shared by cli and mi, but perhaps one could be > created), and left get_prev_frame as a pure stack-traversal function? > That is, if there exists a next-older frame, get_prev_frame will > return it, whether it's in the user's program or part of the > infrastructure. frame_unwind_XXX(here) says get me from HERE to XXX via the most efficient route. It's consistent with the increasingly common frame_unwind_pc, frame_unwind_register, ... As for get_prev_frame, I can think of several possibilities: - publish two interfaces (or parameterize the existing interface) - change to some sort of iterator - introduce a new predicate function indicating if the frame is visible but first, I think the best thing is to eliminate all the almost-dead code. A quick scan reveals much that can be deleted. Wouldn't happen own an ns32k ;-) Andrew