From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29170 invoked by alias); 8 Jul 2004 23:07:26 -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 29150 invoked from network); 8 Jul 2004 23:07:24 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sourceware.org with SMTP; 8 Jul 2004 23:07:24 -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 SAA30946 for ; Thu, 8 Jul 2004 18:27:11 -0400 Received: (from alain@localhost) by smtp.ott.qnx.com (8.8.8/8.6.12) with UUCP id TAA03087 for gdb@sources.redhat.com; Thu, 8 Jul 2004 19:07:22 -0400 Message-Id: <200407082307.TAA03087@smtp.ott.qnx.com> Subject: Re: How does GDB/MI give the current frame To: cagney@gnu.org (Andrew Cagney) Date: Thu, 08 Jul 2004 23:07:00 -0000 From: "Alain Magloire" Cc: nickrob@gnu.org (Nick Roberts), alain@qnx.com (Alain Magloire), drow@false.org (Daniel Jacobowitz), gdb@sources.redhat.com In-Reply-To: <40EDC76F.2070809@gnu.org> from "Andrew Cagney" at Jul 08, 2004 06:15:11 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-07/txt/msg00084.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. > Absolutely!! > > > 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. > Nic, are you using the -var-obj for variables, in theory they have the context i.e. should be thread aware ? > ``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 :-) > 8-) ok. > > 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. > If you are asking if we would want an event for thread selection the same as for frame selection ... The answer is a strong "Yes". Our problems is coordinating the mix of CLI and UI driven actions so things are in sync. So if the user select a new thread via the command line, variables and all othe related views should be updated. The hard lesson learn from the last CDT/Debug release, is that the command prompt will stay and the users(allthough not a majority) that wanted this feature ... are __very__ vocal.