From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21311 invoked by alias); 23 Apr 2008 22:24:38 -0000 Received: (qmail 21295 invoked by uid 22791); 23 Apr 2008 22:24:37 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 23 Apr 2008 22:24:17 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id D050E983DB; Wed, 23 Apr 2008 22:24:15 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id B1D51980F7; Wed, 23 Apr 2008 22:24:15 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1JonNu-00068x-NY; Wed, 23 Apr 2008 18:24:14 -0400 Date: Wed, 23 Apr 2008 23:27:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] -stack-info-frame/-stack-list-frames Message-ID: <20080423222414.GA23569@caradoc.them.org> Mail-Followup-To: Nick Roberts , gdb-patches@sourceware.org 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18447.46315.956290.915310@kahikatea.snap.net.nz> User-Agent: Mutt/1.5.17 (2007-12-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/msg00539.txt.bz2 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. -- Daniel Jacobowitz CodeSourcery