From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Received: (qmail 7021 invoked from network); 10 Jan 2003 20:29:34 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by 209.249.29.67 with SMTP; 10 Jan 2003 20:29:34 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 0503E3E02; Fri, 10 Jan 2003 15:29:23 -0500 (EST) Message-ID: <3E1F2D23.5080304@redhat.com> Date: Fri, 10 Jan 2003 20:29: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: Andrew Cagney Cc: Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: RFC: Mostly kill FRAME_CHAIN_VALID, add user knob References: <20021226191541.GA8483@nevyn.them.org> <3E1F28BB.9080704@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-01/txt/msg00410.txt.bz2 > /* 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. */ > if (inside_entry_file (frame_pc_unwind (fi))) > return 0; > > Should this one be dropped? If the user specified unwind past main, then they problably want _start() included in the backtrace. It's presence also makes the other inside_entry_file() test redundant. Er, I think it should definitly be dropped. The big outstanding problem I've had with the frame rewrite is with trying to re-order FRAME_CHAIN() and FRAME_SAVED_PC() (aka frame_pc_unwind) - the `unwind the pc first' code. I found, for the PPC, that re-ordering things caused test regressions. I think the above runs the exact same risks. If not for the PPC, for some other target. Besides, the other inside_entry_file (get_frame_pc (fi)) test makes it redundant. enjoy, Andrew