From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19496 invoked by alias); 14 Jun 2002 00:30:18 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 19467 invoked from network); 14 Jun 2002 00:30:15 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 14 Jun 2002 00:30:15 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 36AB43CBE; Thu, 13 Jun 2002 20:30:19 -0400 (EDT) Message-ID: <3D09391B.1020700@cygnus.com> Date: Thu, 13 Jun 2002 17:30:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020613 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Seitz Cc: gdb@sources.redhat.com Subject: Re: [MI] -break-insert: (a)synchronous? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-06/txt/msg00105.txt.bz2 > Hi, > > Ok, I believe that there was some general consensus that we want > asynchronus event notifications. Do we also want only one channel for the > notification of these events? > > It seems to me that we've got ways to communicate the breakpoint-create > event: events and commands. Right now, -break-insert overrides the event > handlers so that it can grab the data about the breakpoint when it is > created, but inserting a breakpoint via another interpreter (like the > (Ok, so we could also just add the "bkpt=..." info that is being used in > -break-insert onto this command, but in any case, we get no "event" when > inserting via -break-insert.) > > I would prefer that we use only event notifications, of course. > > That way, the the UI could call -break-info on these events to collect > the information. This way, I only have to write one parser to deal with this > event. (Actually, if I had to deal with both, I would just grab the The command was implemented that way to match its documented spec. I remember wondering about alternate implementations at the time. Sounds like it is time to either define a new command (not capture the events) or change the spec. Andrew