From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29373 invoked by alias); 4 May 2008 11:32:09 -0000 Received: (qmail 29361 invoked by uid 22791); 4 May 2008 11:32:05 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 04 May 2008 11:31:43 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JscRK-0001YA-Sl for gdb-patches@sources.redhat.com; Sun, 04 May 2008 11:31:34 +0000 Received: from 78.158.192.230 ([78.158.192.230]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 May 2008 11:31:34 +0000 Received: from vladimir by 78.158.192.230 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 May 2008 11:31:34 +0000 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: Re: [PATCH:MI] Event notification Date: Sun, 04 May 2008 12:19:00 -0000 Message-ID: References: <18439.56134.456709.118980@kahikatea.snap.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.5 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/msg00165.txt.bz2 Nick Roberts wrote: > 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? > 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? 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 :-) 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. - Volodya