From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32479 invoked by alias); 26 Aug 2002 19:55:40 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 32472 invoked from network); 26 Aug 2002 19:55:38 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 26 Aug 2002 19:55:38 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 46C4D3E12; Mon, 26 Aug 2002 15:55:37 -0400 (EDT) Message-ID: <3D6A87B9.70607@ges.redhat.com> Date: Mon, 26 Aug 2002 13:09:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Seitz Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] gdb-events.sh: selected-frame-level-changed event References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg00861.txt.bz2 > On Sun, 25 Aug 2002, Andrew Cagney wrote: > > >> Ok. > > > Committed. BTW, like any MI change, documentation and a testcase are also needed. >> Any thoughts on how selected-thread events will be handled? They also >> change the selected-fraome. > > > I think that like many events, selected-thread change events imply that a > whole bunch of things have changed, too. For example, a target-stop event > (which we don't really issue as an event like the rest, but it is really > just an event), automatically implies that the selected frame, thread, and > other things have changed, yet we do not issue events for all of these. I > believe that the selected-thread event is the same. GDB doesn't issue a target-stop event because it isn't possible to go back to GDB and ask it why it stopped. The stop message is generated on the fly --- known bug in current implementation :-( > In any case, I'm sure that we've done things wrong. In fact, I'd be > willing to bet that we have. But one small step forward is better than > none. We can always address issues as they appear, which is one of the > nice things about the event mechanisms: GDB itself doesn't use them! They > are UI-specific and quite isolated. :-) We need to be careful though. Otherwize GDB will be locked into supporting something broken for the next N years :-( Andrew