From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18255 invoked by alias); 8 Jul 2004 22:15:30 -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 18245 invoked from network); 8 Jul 2004 22:15:29 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 8 Jul 2004 22:15:29 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i68MFSe3011111 for ; Thu, 8 Jul 2004 18:15:28 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i68MFQ028049; Thu, 8 Jul 2004 18:15:26 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id C11DB2B9D; Thu, 8 Jul 2004 18:15:12 -0400 (EDT) Message-ID: <40EDC76F.2070809@gnu.org> Date: Thu, 08 Jul 2004 22:15:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Nick Roberts , Alain Magloire Cc: Daniel Jacobowitz , gdb@sources.redhat.com Subject: Re: How does GDB/MI give the current frame References: <40DE2D1B.4070003@gnu.org> <200406302047.QAA29956@smtp.ott.qnx.com> <16613.39781.921538.192414@nick.uklinux.net> In-Reply-To: <16613.39781.921538.192414@nick.uklinux.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-07/txt/msg00080.txt.bz2 > > > For the CLI, something like this: > > > > > > -> -interpreter cli "up" > > > <- ~"info on new frame..." > > > <- *select-frame,... > > > <- done Note that the interpreter case is key, it lets the GUI respond to operations on the command line. > > > 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. > > There would still be problems with displaying the values of variables. > Neither variable objects or the CLI command, display, seem to take > notice of the thread number. ``bug'' in current MI protocol. How would something like: -thread 2 - ^done -thread 2 -frame 3 - -frame 3 - ^done grab you? ``-thread'' and ``-frame'' select the thread/frame for _just_ the period of that command. They would not alter the CLI's selected thread/frame (the implementation would for the moment need to be a crock but thats a separate problem :-). This would let the GUI manipulate frames independant of the CLI. > 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 ``bug''. Actually major screwup in how GDB models threads (as in it doesn't really :-) > How about to put the thread-id part ot the event ? So the event would be ``selected changed'' and generated when both switching threads and frames? If it is useful, ok. Andrew