From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11310 invoked by alias); 24 Apr 2008 02:15:39 -0000 Received: (qmail 11301 invoked by uid 22791); 24 Apr 2008 02:15:38 -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; Thu, 24 Apr 2008 02:15:16 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 7F318983DB; Thu, 24 Apr 2008 02:15:14 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 4780F980F7; Thu, 24 Apr 2008 02:15:14 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1JoqzN-0000zw-FW; Wed, 23 Apr 2008 22:15:09 -0400 Date: Thu, 24 Apr 2008 10:24:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] -stack-info-frame/-stack-list-frames Message-ID: <20080424021509.GA3497@caradoc.them.org> Mail-Followup-To: Nick Roberts , gdb-patches@sourceware.org References: <18447.55020.579472.126616@kahikatea.snap.net.nz> <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> <18447.50396.538278.140944@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18447.55020.579472.126616@kahikatea.snap.net.nz> <18447.50396.538278.140944@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/msg00547.txt.bz2 On Thu, Apr 24, 2008 at 11:23:08AM +1200, Nick Roberts wrote: > Well you understand the internals much better than I do, but whenever I've > looked at the frame addresses on i386 they've appeared meaningful. Are > "stackless recursive functions" special to IA-64 or a consequence of > optimisation? If the values are meaningful "most of the time" then I think > it's OK to have this field, if not then I guess it might just confuse. It's an IA-64 thing. This is the original reason that frame IDs had a third member, the "special address" field. I've actually got patches to add several more items to the frame ID. I hope I'll be submitting them soon. That's inlined function support, where the stack address really becomes not useful to identify the scope. On Thu, Apr 24, 2008 at 12:40:12PM +1200, Nick Roberts wrote: > Actually it just needs to be a non-zero value for frames in which a varobj is > created. Perhaps a member of struct frame_id, int varobj_frame say, which > increments when a varobj is created in a new frame. This could also then be > used to see if a varobj has gone out of scope to avoid the ambiguities Jim > Blandy talked about from using frame_find_by_id. > > Perhaps this is what you are suggesting, anyway. Right, this is basically what I had in mind. It may not solve the going out of scope bit, because we don't usually backtrace all the way up - and how do we avoid having to save an unbounded number of these things so we can map them, so maybe a hash is better than a counter. I haven't thought about the details yet. -- Daniel Jacobowitz CodeSourcery