From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-18481-listarch-gdb=sources.redhat.com@sources.redhat.com>
Received: (qmail 3886 invoked by alias); 2 Jul 2004 17:29:54 -0000
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb/>
List-Post: <mailto:gdb@sources.redhat.com>
List-Help: <mailto:gdb-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-owner@sources.redhat.com
Received: (qmail 3878 invoked from network); 2 Jul 2004 17:29:53 -0000
Received: from unknown (HELO nick.uklinux.net) (194.247.50.113)
  by sourceware.org with SMTP; 2 Jul 2004 17:29:53 -0000
Received: by nick.uklinux.net (Postfix, from userid 501)
	id 8FF4675FDE; Fri,  2 Jul 2004 18:29:10 +0100 (BST)
From: Nick Roberts <nickrob@gnu.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16613.39781.921538.192414@nick.uklinux.net>
Date: Fri, 02 Jul 2004 17:29:00 -0000
To: "Alain Magloire" <alain@qnx.com>
Cc: cagney@gnu.org (Andrew Cagney),
	drow@false.org (Daniel Jacobowitz), gdb@sources.redhat.com
Subject: Re: How does GDB/MI give the current frame
In-Reply-To: <200406302047.QAA29956@smtp.ott.qnx.com>
References: <40DE2D1B.4070003@gnu.org>
	<200406302047.QAA29956@smtp.ott.qnx.com>
X-SW-Source: 2004-07/txt/msg00006.txt.bz2

 > > For the CLI, something like this:
 > > 
 > > -> -interpreter cli "up"
 > > <- ~"info on new frame..."
 > > <- *select-frame,<frame-info>...
 > > <- done
 > > 
 > > with similar for -stack-select-frame:
 > > 
 > > -> -stack-select-frame 1
 > > <- *select-frame,<frame-info>,....
 > > <- done
 > > 
 > > Where, yes, <frame-info> would be constructed by calling frame code.
 > > 
 > > -stack-info-frame would just be just:
 > > 
 > > -> -stack-info-frame
 > > <- done,<frame-info>
 > > 
 > > 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.

Nick