From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20947 invoked by alias); 12 Jul 2004 18:48:39 -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 20919 invoked from network); 12 Jul 2004 18:48:37 -0000 Received: from unknown (HELO nick.uklinux.net) (194.247.51.72) by sourceware.org with SMTP; 12 Jul 2004 18:48:37 -0000 Received: by nick.uklinux.net (Postfix, from userid 501) id 0395275FDE; Mon, 12 Jul 2004 19:44:34 +0100 (BST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16626.56338.385281.264806@nick.uklinux.net> Date: Mon, 12 Jul 2004 20:09:00 -0000 To: Andrew Cagney Cc: Nick Roberts , Alain Magloire , gdb@sources.redhat.com Subject: Re: How does GDB/MI give the current frame In-Reply-To: <40F2986D.4010205@gnu.org> References: <40DE2D1B.4070003@gnu.org> <200406302047.QAA29956@smtp.ott.qnx.com> <16613.39781.921538.192414@nick.uklinux.net> <40EDC76F.2070809@gnu.org> <16625.46597.86962.340302@nick.uklinux.net> <40F2986D.4010205@gnu.org> X-SW-Source: 2004-07/txt/msg00114.txt.bz2 Andrew Cagney writes: > > > > > > -> -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. > > > > On my gdb, -interpreter-exec cli "up" gives: > > > > ^error,msg="mi_cmd_interpreter_exec: could not find interpreter \"cli\"" > > (gdb) > > > > I'm still lost here. > > Sorry s/cli/console/, teach me to write something from memory. In that case, I disagree strongly with the suggestion since I think that "-interpreter-exec console" should only give quoted CLI output (plus prefix character). I thought that was the whole idea as it allows front ends to keep the console. Typing CLI input in directly currently gives a mixture of CLI/MI output but this is fine as it is only a temporary/ad hoc means of accessing the CLI. In Emacs, I will run commands from the console with "-interpreter-exec console" and check the status of gdb with a set of MI commands run behind the users back. I imagine a lot of others will do the same, so please don't change this. Earlier, you said > with similar for -stack-select-frame: > -> -stack-select-frame 1 > <- *select-frame,,.... > <- done Can you elaborate? How does "*select-frame" get printed? Does it trigger anything internally? > > > .... How would something like: > > > > > > -thread 2 - > > > ^done > > > -thread 2 -frame 3 - > > > -frame 3 - > > > ^done > > > > Or values could be printed for all threads: > > > > -var-evaluate-expression var1 > > ^done,values=[{thread-id="0",value="0"},{thread-id="1",value="4"},...] > > > > and likewise for other mi commands. This would have the disadvantage of > > breaking existing behaviour but I imagine a user might want to see the value > > of a variable across all threads and would not wish to create a variable > > object for each thread. > > For existing commands, I don't get warm fuzzies. Assuming that the GUI > is only displaying one thread, there's no need to supply the value > across all threads. > > As an extension, I guess, why not. Something like: > > -thread-apply 1 2 3 4 -- -something > ^done,result=[{thread-id="1",result=},{thread-id="2",error=},...] > > or > > -thread-apply * -- -something > ^done,result=[{thread-id="1",result=...},...] > > that is, it returns a list of results from each individual command - > that makes more sense. Yes, that sounds like a good idea. Is it easy to implement? Nick