From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6907 invoked by alias); 5 Jan 2007 20:04:27 -0000 Received: (qmail 6895 invoked by uid 22791); 5 Jan 2007 20:04:26 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 05 Jan 2007 20:04:15 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1H2vIJ-00025D-HB for gdb@sources.redhat.com; Fri, 05 Jan 2007 23:04:10 +0300 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1H2vIJ-000259-52 for gdb@sources.redhat.com; Fri, 05 Jan 2007 23:04:03 +0300 From: Vladimir Prus To: gdb@sources.redhat.com Subject: -var-list --locals proposal Date: Fri, 05 Jan 2007 20:04:00 -0000 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701052303.59465.ghost@cs.msu.su> 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-01/txt/msg00101.txt.bz2 As promised, I have a proposal how to improve local variables display in MI. At the moment, varobjs for locals should be created by frontend, presumably after getting the list of local via -stack-list-locals. That's good, but the list of locals generally change when stepping though the program: 1. When entering or leaving a function, the list of locals changes completely. 2. When entering a nested scope, new locals appear. A variable in a nested scope may have the same name as a variable in an inner scope. 3. When leaving a nested scope, some locals disappears. At the moment, to reliably show all locals, the frontend is forced to emit -stack-list-locals on each step. To handle the case where a new variable is in nested scope and has the same name as a variable in outer scope, the frontend should compute addresses of all variables on each step, and notice when they change. This is rather nasty. I propose to introduce a new command: -var-list --locals This command returns variable objects corresponding to every local variable that is "live" at the current position in the program. If at all possible, the command tries to return previously returned variable object. So, on each step, the frontend emits -var-list --locals and: 1. For all variable objects it never seen, create new GUI elements. 2. For all variable objects that were reported previously, but are no longer reported, delete GUI elements. The 'frame' parameter specifies whose frame's locals should be returned. I envision that varobjs be reused across frames. So, if you invoke: -var-list --locals 1 -exec-finish -var-list --locals 0 the second -var-list will try to return the same varobjs that were returned by the first -var-list. The question is what exactly can be considered "live" variables by -var-list. I think that to avoid creating and destroying variable objects as we step though inner blocks, -var-list should construct varobjs for all variables in all blocks of a function. Then, at each point in the function each varobj can be in one of three states: 1. Accessible in the current scope. 2. Accessible in some of the outer scopes (hidden variable). 3. Not accessible (variable in a scope we've not entered). Transition between those states can be reported via -var-update. The differences between (1) and (3) is already reported via "in_scope" attribute. I'm not sure if we need to expose the difference between (2) and (3), and if so, if it's better to introduce another attribute -- "hidden" with values "true" and "false", or new attribute "visibility", with values of: "yes" "hidden" "out_of_scope" In any way, this is rather small detail that can be changed later. Comments? - Volodya