From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1661 invoked by alias); 29 Aug 2009 05:16:24 -0000 Received: (qmail 1650 invoked by uid 22791); 29 Aug 2009 05:16:22 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS 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.43rc1) with ESMTP; Sat, 29 Aug 2009 05:16:15 +0000 Received: from totara (50.26.255.123.static.snap.net.nz [123.255.26.50]) by viper.snap.net.nz (Postfix) with ESMTP id 933393DA78D; Sat, 29 Aug 2009 17:16:06 +1200 (NZST) Received: by totara (Postfix, from userid 1000) id 4462EC164; Sat, 29 Aug 2009 17:15:59 +1200 (NZST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19096.47503.226488.945344@totara.tehura.co.nz> Date: Sat, 29 Aug 2009 05:40:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: =frame-selected MI notification In-Reply-To: References: <87iqg99xb5.fsf@sphinx.net.ru> From: nickrob@snap.net.nz (Nick Roberts) 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/msg00530.txt.bz2 > 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. I think Emacs, and other frontends that have a console, will always be interested in the current thread/selected frame. The behaviour of CLI commands like up, down, print etc depend on it. Of course, if GDB emits a notification then the frontend can always choose to ignore it. If GDB doesn't emit a notification then the frontend has to send an extra command to get the information it needs after after every user command. It's not only thread and frame changes that could be emitted as notifications. Setting, deleting, disabling breakpoints with CLI commands could also emit notifications. This would save having to send -break-list after every user command. > ... > 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. I think it would be hard to write a large C program with no global variables but, in any case, the concept of current thread/selected frame seems to be a great convenience when using GDB from the command line. -- Nick http://www.inet.net.nz/~nickrob