From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85928 invoked by alias); 8 Jul 2015 17:09:55 -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 85916 invoked by uid 89); 8 Jul 2015 17:09:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-HELO: mail-wi0-f173.google.com Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com) (209.85.212.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 08 Jul 2015 17:09:52 +0000 Received: by wiwl6 with SMTP id l6so351064505wiw.0 for ; Wed, 08 Jul 2015 10:09:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-type:content-disposition:user-agent; bh=EQ+Wkil2ih6kBNeDypAZ/AmlNxDD1ADm5gLPtuHqbQ0=; b=KVcUZ6pDr5+cRtmP2y0lBTJZGGFl5eQxHIbKn9XxL4xicJ5ga7Jawnxozkqzg9k/Lm CnbRuoLSZnMEFT8o8z9l1cf/c9kgyF/37FqG5Jom9I4mYmsn7xWxFd3uC3d+zk9Ig5ao P0Fjz2OwIk6HTXBY2lqDC40sogO7ha8ATIt1/7+Ya0RQAYh0r2JBX4ZpkPxM/lMBiwdS EsEv0Knxue3WoMoE2NnJegDC7m2gp33GLOG82VGkzy2DNBqlhLZrVfkZQHz5Ue/UF4dE VlOPmtQ2L8C0Egjv+cn7wb0Utd95iuHhu3feQp4sn9zbcSGAUpfhimWsTueiofV6AAlE 54qQ== X-Gm-Message-State: ALoCoQkSHqbY4dUqOG//Ffb21wdBT6P/TaShSOBG4v6jYnAfxFPsiqDLOOLbL7obqWOS42xBpkTx X-Received: by 10.194.23.225 with SMTP id p1mr22825072wjf.155.1436375388954; Wed, 08 Jul 2015 10:09:48 -0700 (PDT) Received: from localhost (host81-158-4-174.range81-158.btcentralplus.com. [81.158.4.174]) by smtp.gmail.com with ESMTPSA id fa8sm3883009wib.14.2015.07.08.10.09.47 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jul 2015 10:09:48 -0700 (PDT) Date: Wed, 08 Jul 2015 17:09:00 -0000 From: Andrew Burgess To: gdb-patches@sourceware.org Subject: [RFC] Use of create_new_frame from 'frame'. Message-ID: <20150708170944.GA17985@embecosm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg00241.txt.bz2 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. 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. I wonder then if there's a better way to offer this feature. The two possible choices (other suggestions welcome) are: 1. Create a new command 'create-frame' that takes one or two arguments, and always creates and selects a new frame new frame. The frame command no longer creates new frames. 2. Make 'frame' take an (optional) flag (like 'x', or 'disassemble'), so a user can now say: frame /c STACK-ADDR PC-ADDR in order to create (and select) a new frame. Without the /c flag no new frames are created. With the flag only new frames are created, old frames are not selected. What do people think? Any alternative suggestions? Thanks, Andrew