From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11880 invoked by alias); 24 May 2007 21:56:51 -0000 Received: (qmail 11871 invoked by uid 22791); 24 May 2007 21:56:50 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 24 May 2007 21:56:46 +0000 Received: (qmail 5235 invoked from network); 24 May 2007 21:56:40 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 24 May 2007 21:56:40 -0000 To: Ross Morley Cc: 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> <4654E93A.7090801@tensilica.com> From: Jim Blandy Date: Thu, 24 May 2007 21:56:00 -0000 In-Reply-To: <4654E93A.7090801@tensilica.com> (Ross Morley's message of "Wed, 23 May 2007 18:24:10 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00149.txt.bz2 Ross Morley writes: >>> 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. Well, GDB uses frame IDs itself in many different ways, not just for MI. Frame IDs are the only thing in GDB that can represent a frame from one program pause to the next. So they're used to implement 'next', 'finish', and so on. For those purposes, frame IDs need to be as precise as is practical. If we could, we'd give every frame ever pushed a unique ID. We need to work out how to get the behavior GUIs want from varobjs in terms of those ideal frame IDs. Varobjs are really just little bits of GUI state living inside of GDB, for speed. GDB's job is to keep the GUI up to date on how the GUI's varobjs relate to the program's current state. I don't think GDB should ever delete a varobj itself, except perhaps by prior arrangement with the GUI, for the GUI's convenience. I'd expect the most common use is for varobjs to correspond to GUI expression/variable displays, where the user adds and removes entries. In this use case, having GDB ever delete varobjs is just a pain: the GUI wants them to stick around until some instance of the variable comes back into scope. It's unclear what should happen as the program runs and as the user selects different frames; I have some questions about that that I'll post separately.