From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7348 invoked by alias); 23 Apr 2008 23:04:20 -0000 Received: (qmail 7339 invoked by uid 22791); 23 Apr 2008 23:04:20 -0000 X-Spam-Check-By: sourceware.org Received: from vms048pub.verizon.net (HELO vms048pub.verizon.net) (206.46.252.48) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 23 Apr 2008 23:04:00 +0000 Received: from black ([71.245.67.80]) by vms048.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JZS00CZ8W24SX20@vms048.mailsrvcs.net> for gdb-patches@sourceware.org; Wed, 23 Apr 2008 18:03:41 -0500 (CDT) Received: from bob by black with local (Exim 4.67) (envelope-from ) id 1Joo04-0007zo-C9; Wed, 23 Apr 2008 19:03:40 -0400 Date: Thu, 24 Apr 2008 00:40:00 -0000 From: Bob Rossi Subject: Re: [PATCH] -stack-info-frame/-stack-list-frames In-reply-to: <20080423222414.GA23569@caradoc.them.org> To: Nick Roberts , gdb-patches@sourceware.org Message-id: <20080423230340.GA25265@brasko.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline References: <18446.45778.889114.789630@kahikatea.snap.net.nz> <200804230933.04964.vladimir@codesourcery.com> <18446.63716.779534.2827@kahikatea.snap.net.nz> <200804231349.35190.vladimir@codesourcery.com> <18447.12269.389044.431822@kahikatea.snap.net.nz> <20080423125410.GA19773@caradoc.them.org> <18447.46315.956290.915310@kahikatea.snap.net.nz> <20080423222414.GA23569@caradoc.them.org> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-IsSubscribed: yes 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 X-SW-Source: 2008-04/txt/msg00540.txt.bz2 On Wed, Apr 23, 2008 at 06:24:14PM -0400, Daniel Jacobowitz wrote: > On Thu, Apr 24, 2008 at 10:15:07AM +1200, Nick Roberts wrote: > > But thats a good cas in point. If the frontend end is to operate in a > > stateless manner, as Vladimir has suggested, and varobjs are created in > > non-selected frames, it needs to know the frame addresses: > > > > -var-create - FRAME-ADDR EXPRESSION > > No, it doesn't. We need to kill that interface. It needs to go away. > > You gave a perfect example in your other reply, just now, of why front > ends should not have a frame address. If you are ever in the position > of dealing with a recursive function and you want to know which > instance a variable comes from, the frame address is insufficient. > For instance IA-64 can have stackless recursive functions; they > use only the separate register stack. > > If you want to know which frame the varobj is associated with GDB > should supply some unique opaque identifier, and then the IDE can > use that to show the frame number in a tooltip or wherever. I've got a good idea, how about the frame number? Bob Rossi