From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9104 invoked by alias); 30 Jun 2004 20:47:28 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 9097 invoked from network); 30 Jun 2004 20:47:27 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sourceware.org with SMTP; 30 Jun 2004 20:47:27 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3/8.9.3) with ESMTP id QAA04029 for ; Wed, 30 Jun 2004 16:08:06 -0400 Received: (from alain@localhost) by smtp.ott.qnx.com (8.8.8/8.6.12) with UUCP id QAA27873 for gdb@sources.redhat.com; Wed, 30 Jun 2004 16:47:23 -0400 Message-Id: <200406302047.QAA27873@smtp.ott.qnx.com> Subject: Re: How does GDB/MI give the current frame To: cagney@gnu.org (Andrew Cagney) Date: Wed, 30 Jun 2004 20:47:00 -0000 From: "Alain Magloire" Cc: nickrob@gnu.org (Nick Roberts), drow@false.org (Daniel Jacobowitz), gdb@sources.redhat.com In-Reply-To: <40DE2D1B.4070003@gnu.org> from "Andrew Cagney" at Jun 26, 2004 10:12:43 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-06/txt/msg00311.txt.bz2 > > > Daniel Jacobowitz writes: > > DJ> > > DJ> Why not use -stack-info-frame? > > > > Because AFAIK this MI command has not been implemented (yet). > > > > Andrew Cagney writes: > > > > AC> When the user does "up", "down", the debugger should generate a selected > > AC> CLI frame changed event (it currently doesn't). If the GUI so chooses, > > AC> it can track the users "selected" frame, by responding to these events. > > > > I don't know what a selected CLI frame changed event is but up, down, and > > frame generate MI output, so I imagine its just a case of hooking > > -stack-info-frame and -stack-select-frame to that output. I will try to do > > this if you think it's appropriate. > > For the CLI, something like this: > > -> -interpreter cli "up" > <- ~"info on new frame..." > <- *select-frame,... > <- done > > with similar for -stack-select-frame: > > -> -stack-select-frame 1 > <- *select-frame,,.... > <- done > > Where, yes, would be constructed by calling frame code. > > -stack-info-frame would just be just: > > -> -stack-info-frame > <- done, > > The important thing is that, in both cases, the GUI is being driven by > the select-frame event. > Cool !! One thing: -thread-select 2 ^done,... -stack-select-frame 3 ^done -thread-select 1 ^done,.. -thread-select 2 ^done,.. If you would do "-stack-info-frame" now, you would notice that current stackframe for thread 2 is not longer frame 3 but frame 0 !! It this case would not it be appropriate to fire a "*select-frame" event. Second thing: Playing with MI, I've notice in between -var-update|-var-delete|etc .. operation the frame selection level was reset to 0, failing the other operations that was still assuming a certain frame level. Now is this an appropriate behaviour? or a bug? if it is appropriate should client recall -stack-select-frame XX all the time to make sure things are ok > Andrew > > PS: Better / more consistent event name welcome. > How about to put the thread-id part ot the event ?