From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32078 invoked by alias); 8 May 2002 02:03:57 -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 32067 invoked from network); 8 May 2002 02:03:54 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 8 May 2002 02:03:54 -0000 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id TAA10747; Tue, 7 May 2002 19:03:50 -0700 (PDT) Message-ID: <3CD88478.D42E4D5A@redhat.com> Date: Tue, 07 May 2002 19:03:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: Michael Snyder , gdb-patches@sources.redhat.com Subject: Re: [RFA/RFC] Tweak for a gdb.mi test. References: <200205080109.g4819B821604@reddwarf.sfbay.redhat.com> <20020508013041.GA29600@nevyn.them.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-05/txt/msg00191.txt.bz2 Daniel Jacobowitz wrote: > > On Tue, May 07, 2002 at 06:09:11PM -0700, Michael Snyder wrote: > > > > I'm gonna ask for a second pair of eyes, since I don't know MI > > very well. > > > > What this is -- the test is examining the stack, but it is > > assuming that main is the last frame. My change allows for > > one extra frame below main (eg. for '_start'). > > > > OK to check in? > > Before you check this in, I would prefer to have a policy decision > in place about whether we should show that frame or not. The relevant > macro is FRAME_CHAIN_VALID; I believe we should universally (or almost > universally) change this to stop at main. I think that's > func_frame_chain_valid but don't trust my memory. > > Some ports (HP/UX comes to mind) do wacky things in this macro/method. > I'm not sure what they accomplish or whether they are really necessary. > Most default to either file_ or func_, and we should standardize that > unless there is a good reason not to. I don't think we can do that, Daniel -- that would force us to change numerous existing target ports. Retroactive requirements are not generally a good idea. AFAICT, we're stuck with the fact that this has not been standardized in the past. I would guess that there are just as many targets that display the _start frame as don't.