From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3098 invoked by alias); 28 Aug 2009 06:16:50 -0000 Received: (qmail 3088 invoked by uid 22791); 28 Aug 2009 06:16:48 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 28 Aug 2009 06:16:42 +0000 Received: from list by lo.gmane.org with local (Exim 4.50) id 1MgulL-0004AI-DM for gdb-patches@sources.redhat.com; Fri, 28 Aug 2009 08:16:39 +0200 Received: from h86-62-88-129.ln.rinet.ru ([86.62.88.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 28 Aug 2009 08:16:39 +0200 Received: from vladimir by h86-62-88-129.ln.rinet.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 28 Aug 2009 08:16:39 +0200 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: Re: =frame-selected MI notification Date: Fri, 28 Aug 2009 06:44:00 -0000 Message-ID: References: <87iqg99xb5.fsf@sphinx.net.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.9 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: 2009-08/txt/msg00508.txt.bz2 Tom Tromey wrote: >>>>>> "Dmitry" == Dmitry Dzhus writes: > > Dmitry> Nick Roberts once posted a patch which implements both =thread-selected > Dmitry> and =frame-selected via observers: > Dmitry> http://sourceware.org/ml/gdb-patches/2008-04/msg00377.html. > > I didn't see any discussion of this patch in the archives. > Was it just forgotten? > > In general I think that it makes sense to have MI notifications for > state changes caused by CLI commands. > > Dmitry> Current implementation of =thread-selected in mi-main.c uses a > Dmitry> different approach, comparing current thread ID before and after > Dmitry> executing a command in `mi_execute_command` function. My patch > Dmitry> does the same for frame level. I don't know how is it > Dmitry> technically better. I think it would be nice if somebody > Dmitry> reviewed Nick's patch once again or at least accepted the one > Dmitry> proposed by me. > > I tend to prefer Nick's approach. I like the use of observers. I'll review this patch later, but I wanted to clarify this point. The current codebase emits =thread-selected already, and it does not use observers, by design. The reason is that MI frontend is not actually interested in changes in GDB's current thread. The design I am pushing for is that frontend maintains the current thread and frame (possibly, different for different main window, even) and uses --thread and --frame options to MI commands to obtain necessary information in the context of the desired thread. The only thing frontend might want to know from GDB is that a CLI command has explicitly asked to change thread or frame -- in which case frontend might want to switch its own current thread or frame. To reiterate, frontend does not care about thread or frame switches that GDB might do internally. It was decided that the easiest way to detect such explicit request from the user is to note that thread has changed after an MI command was executed. It seems reasonable to apply the same logic to frame. Furthermore, I do not think that observers for either thread or frame changes is good idea, design wise. The fact that gdb has current thread or current frame at the code level, is, IMNSHO, a design bug. Global variables are generally bad, and those two are certainly not exception. It's better not to make situation worse by adding new mechanism based on that design bug. - Volodya