From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5253 invoked by alias); 15 Jul 2004 14:42:49 -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 5133 invoked from network); 15 Jul 2004 14:42:46 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 15 Jul 2004 14:42:46 -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 i6FEgke3010546 for ; Thu, 15 Jul 2004 10:42:46 -0400 Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6FEgj022556; Thu, 15 Jul 2004 10:42:45 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 380B92B9D; Thu, 15 Jul 2004 10:42:47 -0400 (EDT) Message-ID: <40F697E7.9060904@gnu.org> Date: Thu, 15 Jul 2004 14:48: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 Cc: Alain Magloire , 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> <40EDC76F.2070809@gnu.org> <16625.46597.86962.340302@nick.uklinux.net> <40F2986D.4010205@gnu.org> <16626.56338.385281.264806@nick.uklinux.net> In-Reply-To: <16626.56338.385281.264806@nick.uklinux.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-07/txt/msg00169.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. (Looks like my yesterday reply died along with my battery :-() That's almost the whole idea. The -interpreter-exec command provides two mechanism to the GUI/client: - the ability to access GDB's `console' vis: -> -interpreter cli "up" <- ~"info on new frame..." <- done - the ability to notify the GUI of console sideeffects vis: <- *select-frame,... > 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. Wouldn't these polling commands need to be run behind the users back after every CLI command? By monitoring these events, the GUI can avoid polling except when needed. > 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? An observer would be needed. > > > > .... 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? It should be fairly straight forward. Have a look at ``info threads''. Andrew