Re: [PATCH] Hooks still needed for annotations

[Daniel Jacobowitz <drow at false dot org>]

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.

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.

- 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.

-- 
Daniel Jacobowitz
CodeSourcery, LLC