From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8847 invoked by alias); 10 Jun 2008 22:04:10 -0000 Received: (qmail 8839 invoked by uid 22791); 10 Jun 2008 22:04:09 -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; Tue, 10 Jun 2008 22:03:41 +0000 Received: from kahikatea.snap.net.nz (72.31.255.123.static.snap.net.nz [123.255.31.72]) by viper.snap.net.nz (Postfix) with ESMTP id 50F483DA0D9; Wed, 11 Jun 2008 10:03:32 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 8C9668FC6D; Wed, 11 Jun 2008 10:03:30 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18510.64049.562871.546098@kahikatea.snap.net.nz> Date: Wed, 11 Jun 2008 00:08:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: [patch:MI] Observer for thread-changed In-Reply-To: <200806101232.37186.ghost@cs.msu.su> References: <18509.7945.19078.399646@kahikatea.snap.net.nz> <200806101057.19272.ghost@cs.msu.su> <18510.14942.143700.410083@kahikatea.snap.net.nz> <200806101232.37186.ghost@cs.msu.su> 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-06/txt/msg00211.txt.bz2 > > > Are you planning to write tests, and document the new notification? > > > > There certainly should be tests and documentation, and I will do write > > some, but I don't see any for the existing notifications, namely > > "thread-created" and "thread-exited". > > You probably missed those. Here's what my checkout of gdb.texinfo reads: > > @item =thread-created,id="@var{id}" > @itemx =thread-exited,id="@var{id}" > A thread either was created, or has exited. The @var{id} field > contains the @value{GDBN} identifier of the thread. OK. Are there any tests? I think that event notifications should have their own node. I also think that the manual should be restructured so that the node "GDB/MI Output Records" comes _under_ the node "GDB/MI Command Syntax" and that the nodes in "GDB/MI Output Records" are linked with their description in "GDB/MI Output Syntax" > > You could say the same about user-defined functions that use the "threads" > > command. > No, because user-defined functions are typed by the user and passed through > to GDB, and if those commands change thread, UI should update. On the > contrary, if the frontend sent -thread-select, it means it wanted to set GDB > current thread to be the same as the current thread presently shown in the > UI, so I see no point for frontend to be notified. Can you outline a use case > where frontend would actually like to be notified about the thing it just > did? In my scenario the frontend would automatically display the selected thread, not select the thread that is displayed. > > I don't think MI should be used as a programming language. I don't think > > -thread-select should be used by the front end except when the user > > explicitly requests to change threads. In fact, I would even suggest that > > there should be no -thread-select and that all MI commands should be > > reflective > What is "reflective"? Maybe it's not the right word. Perhaps I mean introspective, i.e., just reports the state like -break-list or -environment-pwd and doesn't change it like -thread-select or -stack-select-frame, for example. > > With a complete set of notifications, the usual CLI commands could be used > > to change state and the front end could just parse the MI output. > Could be used where? If in GDB console, then sure, but that does not require > that -thread-select output notification. I mean the front end could just use CLI commands to change the state provided there were MI notifications that would report that change. > > But the first patch was wrong for other reasons, as Pedro pointed out. > IIUC, the primary objection was that we'd emit notification even if > gdb_thread_select caught an exception. Can we protect against this by > checking that inferior_ptid actually changed? Pedro says he has a patch that splits the notion of user/frontend selected thread and frame, from the internally selected thread and frame. Let's wait to see how that fits in. -- Nick http://www.inet.net.nz/~nickrob