From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35678 invoked by alias); 8 Jul 2015 18:02:09 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 35646 invoked by uid 89); 8 Jul 2015 18:02:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 08 Jul 2015 18:02:05 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 36D7A2B7877; Wed, 8 Jul 2015 18:02:04 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t68I2272012510; Wed, 8 Jul 2015 14:02:03 -0400 Message-ID: <559D659A.50704@redhat.com> Date: Wed, 08 Jul 2015 18:02:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Andrew Burgess , gdb-patches@sourceware.org Subject: Re: [RFC] Use of create_new_frame from 'frame'. References: <20150708170944.GA17985@embecosm.com> In-Reply-To: <20150708170944.GA17985@embecosm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-07/txt/msg00243.txt.bz2 On 07/08/2015 06:09 PM, Andrew Burgess wrote: > The 'frame' command can cause 'create_new_frame' in some conditions: > > - When two arguments are passed, or > - When one argument is passed that is not: > - A valid index into the backtrace, or > - A valid stack frame base address. > > Personally, I dislike this behaviour because: > > 1. It's easy to make a mistake using the frame command and create a > new frame. It's not obvious (I think) how to recover from this > situation. [ The answer is just to use 'frame' again with a > valid frame specifier argument. ] > > 2. As a backtrace can be possibly any depth then depending on where > we stop alters which frames we can create. This seems a little > arbitrary. > Totally agreed. See here for my previous suggestions: https://sourceware.org/ml/gdb/2014-11/msg00028.html Related bugs: https://sourceware.org/bugzilla/show_bug.cgi?id=18074 https://sourceware.org/bugzilla/show_bug.cgi?id=8864 > We could improve #1 by not allowing small indexes that are close to > the number of frames in the backtrace, however, this feels like a bit > of a hack, and would be a little annoying on small targets where low > value addresses are actually valid. Yeah, yuck. :-) Thanks, Pedro Alves