From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14164 invoked by alias); 24 May 2007 01:24:15 -0000 Received: (qmail 14155 invoked by uid 22791); 24 May 2007 01:24:14 -0000 X-Spam-Check-By: sourceware.org Received: from hq.tensilica.com (HELO mailapp.tensilica.com) (65.205.227.29) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 24 May 2007 01:24:13 +0000 Received: from localhost ([127.0.0.1]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1Hr23m-0001DP-QL; Wed, 23 May 2007 18:24:10 -0700 Received: from mailapp.tensilica.com ([127.0.0.1]) by localhost (mailapp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02654-04; Wed, 23 May 2007 18:24:10 -0700 (PDT) Received: from nose.hq.tensilica.com ([192.168.11.18]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1Hr23m-0001DJ-Bh; Wed, 23 May 2007 18:24:10 -0700 Message-ID: <4654E93A.7090801@tensilica.com> Date: Thu, 24 May 2007 01:24:00 -0000 From: Ross Morley User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 MIME-Version: 1.0 To: Ross Morley CC: Jim Blandy , Maxim Grigoriev , gdb@sourceware.org, Marc Gauthier , Pete MacLiesh Subject: Re: Understanding GDB frames References: <46521C04.7040405@hq.tensilica.com> <465341B8.9060208@hq.tensilica.com> <46538818.1050601@tensilica.com> <4653A5F3.60503@tensilica.com> In-Reply-To: <4654D6CC.1080604@tensilica.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-05/txt/msg00147.txt.bz2 Ross Morley wrote: > > So the answer to Daniel's question: > >> But what we do need is to clarify our semantics so >> >>> that front ends know what to expect. Should varobjs be destroyed when >>> we leave and re-enter a function? If the answer is "maybe", then that >>> is confusing enough to deserve some more explanation :-) >> >> >> > seems to be an unambiguous "no". > > This begs the question: when should GDB destroy a varobj? I need to revisit this. It's not clear that GDB destroys a varobj at all unless the GUI tells it to. It seems GDB tells the GUI the varobj went out of scope, and the GUI then doesn't update it. The GUI's concept of scope is different than the language concept. A var is considered in_scope if an instance of its function exists in the stack frame (*). So perhaps GDB should not say it's not in_scope if any instance of it still exists, even if it's a different instance than when the varobj was created. That is, the frame ID should not determine whether a varobj is in_scope for MI. A mere search of the frame stack for any frame with the same entrypoint (same function) should indicate in_scope. (*) Before GDB 6 and the new frame ID, it seems varobj.c looked for the frame address still being in the stack. So it may be that MI considers a var "in scope" if its function is still on the stack at the same level, but not if it's at a different level. This seems less ideal for the GUI but is what GDB achieves when frame ID uses only stack ptr and PC at function entry. To avoid possibly breaking assumptions made by MI clients, it might be best to simply require that a gdbarch compute frame IDs based only on frame location in stack(s) and function entrypoint (and explicitly NOT try to make frame ID represent a unique instantiation of a function). This requires no change to generic GDB. If GUI people think it would provide better behavior and can ensure their GUIs don't rely on the present behavior, GDB could in future relax its in_scope determination for MI vars. Ross