From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22611 invoked by alias); 14 Jun 2002 02:27:07 -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 22586 invoked from network); 14 Jun 2002 02:27:06 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 14 Jun 2002 02:27:06 -0000 Received: from makita.cygnus.com (makita.sfbay.redhat.com [192.168.30.83]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id TAA16776 for ; Thu, 13 Jun 2002 19:27:06 -0700 (PDT) Received: from localhost (keiths@localhost) by makita.cygnus.com (8.8.8+Sun/8.6.4) with ESMTP id TAA10811 for ; Thu, 13 Jun 2002 19:27:05 -0700 (PDT) X-Authentication-Warning: makita.cygnus.com: keiths owned process doing -bs Date: Thu, 13 Jun 2002 19:27:00 -0000 From: Keith Seitz X-X-Sender: To: Subject: Re: [MI] -break-insert: (a)synchronous? In-Reply-To: <3D09391B.1020700@cygnus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-06/txt/msg00106.txt.bz2 On Thu, 13 Jun 2002, Andrew Cagney wrote: > 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. Ok, then I would like to propose that we change the spec to use events and only events when a command results in some event. This reduces the redundancy. I'm working on modifying gdbmi.texinfo, but I am a little confused about all the stream options: "*" = "exec-async-output" "+" = "status-async-output" "=" = "notify-async-output" >From the manual ([] = my comments): o status-async-output contains on-going status information about the progess of slow operation. All status output is prefixed by "+". [I presume that the biggest client for this is downloading to a target.] o exec-async-output contains asynchronous state change on the target (stopped, started, disappeared). All Async output is prefixed by "*". [This seems to be called only by async target state changes.] o notify-async-output contains supplementary information that the client should handle (e.g., a new breakpoint information). All notify output is prefixed by "=". [I don't know where this is used. I am unable to find any references to this.] >From the descriptions above, it sounds like event notifications should occur on the notify-async-output channel, "=". However, if one reads down to the "Command With Side Effects" section, one sees: -> -symbol-file xyz.exe <- *breakpoint,nr="3",address="0x123",source="a.c:123" <- (gdb) The exact meaning of this example is not really clear to me, but I presume that it is meant to demonstrate what happens when a breakpoint is inserted as a result of loading a new symbol file (however that may occur). In any case, the example is certainly not exec-async-output. In fact, it is nothing in the MI lingo. To get the ball rolling on cleaning some of this up, I will submit a patch which changes (replaces?) the meaning of notify-async-output to include events in the debugger (breakpoints inserted/deleted/modified, architecture changes, stack frame changes, switching current thread, etc), and I will update all the examples. If someone reads this differently than I do, please speak up. So, here's how I interpret what should happen: (gdb) -break-insert main =breakpoint-create,number="1" ^done,bkpt=... (gdb) (I will also be proposing that we whack the result in this case, since we will get an event notification, too.) Keith