Re: [PATCH] Hooks still needed for annotations

[Bob Rossi <bob@brasko.net>]

On Fri, Jun 03, 2005 at 07:59:24PM -0400, Daniel Jacobowitz wrote:
> On Sat, Jun 04, 2005 at 10:33:58AM +1200, Nick Roberts wrote:
> > 
> >  > > I don't currently use breakpoints-invalid but I might wish to at one
> >  > > stage.  I want to ensure that annotations aren't quietly removed by
> >  > > dismantling them bit by bit.
> >  > 
> >  > If that's what you want to accomplish, your patch should include test
> >  > cases for these annotations.  Otherwise they're likely to be "cleaned
> >  > up".  Also, please do not comment out code; if it's wrong, it should be
> >  > deleted.
> > 
> > I left the comment there to try to prevent them being removed again. If
> > I remove then I would also like to remove the deprecated prefix for the
> > two hooks.
> 
> They are deprecated.  I believe there's a clear consensus that the
> entire annotation system is going to go, and in the near future.  Just
> not yet.

I hope that the annotations can stay until Nick and I, along with the
Apple and Eclipse people think that the MI is stable and ready for use.

For instance, I know that the Apple guys have patched MI in order for
there parser to know when it is recieving an asyncronous command. I
haven't got that far, but would like to see such a think in the FSF GDB.
Also, last time I looked at Eclipse's source code, they were still using
a hybrid GDB/CLI implementation because MI simply didn't support all of
the features that they are using.

Also, I think it's reasonable to say that GDB should have a parser that
FE's can use. The only way to have a parser that can be tested properly
is to allow it to be packaged and tested in GDB's testsuite. Otherwise,
if the annotations are removed, FE's like GVD, XXGDB, DDD, KGDB, ...
are either going to "go the way of the bison" or they are going to have
to write code that handles GDB/MI. Do we really want 5-10 GDB/MI
parser's out there (each with there own bugs)?

> The way to prevent them from being removed again is to add test cases.
> 
> > The point about keeping them is that they can be used for event notification
> > in MI (Tue, 8 Feb 2005 10:14:31 +1300).
> > 
> > Th manual says:
> > 
> > > `ASYNC-CLASS ==>'
> > >      `"stopped" | OTHERS' (where OTHERS will be added depending on the
> > >      needs--this is still in development).
> > 
> > I do not have enough knowldege of GDB to work out when breakpoint information
> > changes in the code. So I would like to use the calls to breakpoints_changed
> > (breakpoints-invalid) to do this and generate MI output:
> > 
> > =breakpoint-changed,BreakpointTable={nr_rows...
> 
> I don't know enough about MI yet to know if this is the right way to do
> that.  I don't think it is.
> 
> - Certainly we should not be outputting the whole breakpoint table. 
> We'd want a way to represent the changes.

Yeah, this is a good point. If we follow the annotations route, we could
just alert the FE that the breakpoints have changed and then force them
to get the new list.

The wierd thing is, there is situations in GDB with annotations where
GDB just spews out breakpoints-invalid over and over and over again. It
creates a lot of I/O and is a source of trouble. I believe this happens
when part of the code you are stepping though was not compiled with
debug?
> - Breakpoints changing is not an asynchronous event.  Stopped is an
> async event; breakpoint-deleted is a synchronous event, even if it
> comes from the user typing in a console window.

It fits much nicer into the asyncronous case that nick posted. If
we want to make it syncronous then I think there would have to be a
change to the MI protocol.

output ==>
    ( out-of-band-record )* [ result-record ] [ status-update ] "(gdb)" nl 

Thanks,
Bob Rossi