From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3235 invoked by alias); 4 May 2008 22:23:48 -0000 Received: (qmail 3227 invoked by uid 22791); 4 May 2008 22:23:47 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 04 May 2008 22:23:18 +0000 Received: from kahikatea.snap.net.nz (28.62.255.123.dynamic.snap.net.nz [123.255.62.28]) by viper.snap.net.nz (Postfix) with ESMTP id A76993D8139; Mon, 5 May 2008 10:23:14 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 8E4DB8FC6D; Mon, 5 May 2008 10:23:10 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18462.14156.718118.45321@kahikatea.snap.net.nz> Date: Sun, 04 May 2008 23:19:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH:MI] Event notification In-Reply-To: References: <18439.56134.456709.118980@kahikatea.snap.net.nz> X-Mailer: VM 7.19 under Emacs 22.2.50.2 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-05/txt/msg00188.txt.bz2 > > This patch adds event notification for changes in selected frame and > > thread. In annotations, file and line information are output when the > > program stops and when the selected frame is changed, e.g., with "up" or > > "down". Currently in MI this information is only output for the former > > case. For threads, -thread-info doesn't give the selected frame and this > > may currently change when execution stops. > > I think that when execution stops, all threads have frame 0 as selected, no? All threads may have frame 0, but the frame details are different, e.g. currently: -thread-select 2 ^done,frame={level="0",addr="0x08048968",func="myproc",args=[{name="ptr_i",value="0xbff4f73c"}],file="pthreadtest.c",fullname="/home/nickrob/C/pthreadtest.c",line="91"} (gdb) -thread-select 4 ^done,frame={level="0",addr="0x08048859",func="myproc",args=[{name="ptr_i",value="0xbff4f744"}],file="pthreadtest.c",fullname="/home/nickrob/C/pthreadtest.c",line="53"} (gdb) > > In any case, providing a notification it means that the frontend > > doesn't need to interrogate Gdb. > > > > A further advantage of using notifications is that they are output even > > when a CLI command is issued from the console. I've discussed these ideas > > on the mailing list before but not used observers and in the past I've got > > a bit hung up on trying to detect changes in stack (too difficult). > > > > I've not run the testsuite as I imagine it will break in many places. I > > want to get this idea of decoupling MI output from the input command > > accepted first. In this respect, it is somewhat similar to asynchronous > > output in asynchronous mode. > > Some interesting questions arise, with the first one -- what is the exact > meaning of those new notifications and what is the expected reaction in > frontend? For example, suppose you have a bunch of fixed variable objects > in different threads. Then, -var-update * will switch between threads to > evaluate the variable objects. This, I think, will produce a bunch of thread > change and frame change notifications? It currently issues a load of frame change notifications but no thread change ones, just because the observer isn't registered in switch_to_thread. > What will frontend do? If a frontend > updates the current line indicator as result of those notifications, then > "-var-update *" will cause the line indicator to jump around in a fairly > interesting way :-) In annotations, you can prefix a command with "server" so that it doesn't get added to the command history. I guess you could have a similar convention here: a token of 0 means don't print notifications, e.g, ^0-var-update --all-values * If we do this now, it will be backward compatible because AFAIK released Gdb doesn't print event notifications. > One way to address this is to suppress those notification for implicit > gdb activity. I don't see how we can easily do this. Another way would > be instruct the frontends to ignore those notifications during some commands. > But then, I'm not sure how to do this without creating a huge table of > commands that implicitly change thread/stack, and without running the risk > of making the frontend act funny if we forget a command, or unintentionally > make some other command switch thread/frames. -- Nick http://www.inet.net.nz/~nickrob