From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5369 invoked by alias); 15 Jun 2008 17:43:05 -0000 Received: (qmail 5361 invoked by uid 22791); 15 Jun 2008 17:43:05 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 15 Jun 2008 17:42:47 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.63) (envelope-from ) id 1K7wFV-0003B3-Ve for gdb-patches@sources.redhat.com; Sun, 15 Jun 2008 21:42:45 +0400 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1K7wFQ-0003AY-LH; Sun, 15 Jun 2008 21:42:36 +0400 From: Vladimir Prus To: Nick Roberts , gdb-patches@sources.redhat.com Subject: Re: [patch:MI] Observer for thread-changed Date: Sun, 15 Jun 2008 21:03:00 -0000 User-Agent: KMail/1.9.9 References: <18509.7945.19078.399646@kahikatea.snap.net.nz> <20080614191328.GA11666@caradoc.them.org> <18516.16499.732319.353988@kahikatea.snap.net.nz> In-Reply-To: <18516.16499.732319.353988@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806152142.36083.ghost@cs.msu.su> 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/msg00277.txt.bz2 On Sunday 15 June 2008 02:04:35 you wrote: > > > In other words, I argue for notification to be designed with the view of > > > what frontend is supposed to do with it, not with what internal detail of > > > GDB is been reported. > > > > This is a good principle, but it's not right either. Reporting the > > internal state of GDB is bad design, but reporting based on what > > frontends are supposed to do is also bad design: it assumes that you > > can think of everything a frontend might want to do. We need to > > report logical interface events based on GDB's state. > > I agree. I don't think that we should second guess what front ends will do. We should, or frontends will second guess what MI tells them. "Current thread" is not a exact thing, and "current thread changed" is not an exact thing either, so we should provide specific meaning that is most useful to frontends, and opposed to providing a meaning that is most easy for gdb. > I > think the role of MI is to provide a mechanism to report the state of GDB and > the inferior, not to provide a policy. The front end developer can then filter > out information that he doesn't need. However he can't factor in information > that GDB developers leave out because they consider it's not needed. I'd say that gdb already provides sufficient information in response to -thread-select, namely either ^done or ^error. Unless GDB has a bug, the output of ^done means that the thread has changed. - Volodya