From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16976 invoked by alias); 24 May 2002 20:41:35 -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 16952 invoked from network); 24 May 2002 20:41:33 -0000 Received: from unknown (HELO localhost.redhat.com) (66.31.105.161) by sources.redhat.com with SMTP; 24 May 2002 20:41:33 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id DCBCA3D1A; Fri, 24 May 2002 16:41:46 -0400 (EDT) Message-ID: <3CEEA58A.8090209@cygnus.com> Date: Fri, 24 May 2002 13:41:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0rc2) Gecko/20020518 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Seitz Cc: gdb@sources.redhat.com Subject: Re: [MI] Synchronous event notification References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-05/txt/msg00271.txt.bz2 (I had to go and read over some old notes). > I've been working on integrating Apple's "-interpreter-exec" changes, and > I wanted to see if I could get some sort of consensus on how event > notifications should be defined. > > In the trunk right now, MI ignores event notifications. Adding a mechanism > is vital to the success of MI. > > Apple has added this, and all event notifications are tacked onto the > mi-command result: > > (gdb) > -interpreter-exec console "break main" > Breakpoint 1 at ... > ^done,MI_HOOK_RESULT=[HOOK_TYPE="breakpoint_create",bkpt={number="1",...}] Looking at the old notes, I think the intent was: (gdb) -interpreter-exec console "break main" &"Breakpoint 1 at ..." *breakpoint-create,pkpt={number="1',...} ^done The actual example I found was: > Command with side effects: > -> -symbol-file xyz.exe > <- *breakpoint nr=3 address=0x123 source=a.c:123 > <- (gdb) It is a really old example and you can see how the syntax evolved :-) > Right now, this is done by defining a bunch of (existing) hooks when mi > runs. I presume that we want to switch over to using gdb-events, hoping > one day to deprecate the hooks, but that's not really the issue (since > they behave essentially the same in non-asynch). Yes, they are essentially the same. The gdb-events just tries to collect everything together. The idea being that, for instance, several things could ``observe'' GDB. However, it might just be over-engineering. > The real question is, how > do maintainers want this information communicated to mi clients? > The example above shows that Apple has added a syntax like: > > result ==> > stuff [ "," event-list ] > event-list ==> > "MI_HOOK_RESULT=[" event ( "," event )* "]" > event ==> > "HOOK_TYPE=" event-name [ event-data ] > event-name ==> > "breakpoint_create" | "breakpoint_delete" | ... > > and such. > > Since hooks are really just event notifications, I would like to propose > that we use a definition like the above, but changing the string literals > a litte: > > event-list ==> > "events=[" event ( "," event )* "]" > event ==> > "name=" event-name [ event-data ] > event-name ==> > "breakpoint_create" | "breakpoint_delete" | ... So: ^done,result=...,events=... So that, for a ``synchronous'' command the events just get bundled with the result. Sounds ok, definitly has a certain elegance - here is the result, here are all the sideeffects. One question, what about a more asynchronous operation? A running target starts loading shared libraries, inserting breakpoints, running scripts, et.al. There the synchronous nature is gone. I guess: - notify of all the events when the target next ``stops'' - notify the events on-the-fly (possibly incuring an overhead?) Andrew > Please discuss. > Keith