From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6213 invoked by alias); 24 Apr 2008 23:04:38 -0000 Received: (qmail 6205 invoked by uid 22791); 24 Apr 2008 23:04:37 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 24 Apr 2008 23:04:08 +0000 Received: from kahikatea.snap.net.nz (194.30.255.123.static.snap.net.nz [123.255.30.194]) by viper.snap.net.nz (Postfix) with ESMTP id 570283DAFAD; Fri, 25 Apr 2008 11:04:05 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 25BAF8FC6D; Fri, 25 Apr 2008 11:03:53 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18449.4568.206733.6318@kahikatea.snap.net.nz> Date: Fri, 25 Apr 2008 01:48:00 -0000 To: Daniel Jacobowitz Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] -stack-info-frame/-stack-list-frames In-Reply-To: <20080424021509.GA3497@caradoc.them.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> <20080424021509.GA3497@caradoc.them.org> X-Mailer: VM 7.19 under Emacs 22.2.50.2 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/msg00564.txt.bz2 > > 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. So it's really an exceptional case rather than the rule. > 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. Maybe Gdb could somehow identify the cases where the address isn't useful. > 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. I don't think the number need be that unbounded, it's not needed for each frame, only those in which a varobj is created. But it appears that the linked list of frames gets destroyed and recreated each time execution occurs, in which case any id information is also lost (I was looking at using an extra member in struct frame_info). -- Nick http://www.inet.net.nz/~nickrob