[PATCH] Hooks still needed for annotations

[PATCH] Hooks still needed for annotations

[Nick Roberts]

On 2004-04-21 the lines below were added to clear_interpreter_hooks in
interps.c:

  deprecated_delete_breakpoint_hook = 0;
  deprecated_modify_breakpoint_hook = 0;

Previously they were set to breakpoint_changed (a more natural name would be
annotate_breakpoints_invalid).  This means that sometimes breakpoints-invalid
annotations aren't generated. In particular this is the case when a breakpoint
is toggled between its enabled state and disabled state.

Although the intention is to eventually remove annotations I don't think this
stage has been reached yet and it makes little sense to remove a small
number of calls. The patch below re-instates them.

Nick


2005-06-01  Nick Roberts  <nickrob@snap.net.nz>

	* interps.c (clear_interpreter_hooks):
	Re-instate deprecated_delete_breakpoint_hook and
	deprecated_modify_breakpoint_hook for annotations.


*** /home/nick/src/gdb/interps.c.~1.15.~	2005-04-26 21:44:15.000000000 +1200
--- /home/nick/src/gdb/interps.c	2005-06-01 19:10:35.000000000 +1200
***************
*** 326,333 ****
    deprecated_query_hook = 0;
    deprecated_warning_hook = 0;
    deprecated_create_breakpoint_hook = 0;
!   deprecated_delete_breakpoint_hook = 0;
!   deprecated_modify_breakpoint_hook = 0;
    deprecated_interactive_hook = 0;
    deprecated_registers_changed_hook = 0;
    deprecated_readline_begin_hook = 0;
--- 326,334 ----
    deprecated_query_hook = 0;
    deprecated_warning_hook = 0;
    deprecated_create_breakpoint_hook = 0;
!   /* These hooks are needed for annotations
!      deprecated_delete_breakpoint_hook = 0;
!      deprecated_modify_breakpoint_hook = 0; */
    deprecated_interactive_hook = 0;
    deprecated_registers_changed_hook = 0;
    deprecated_readline_begin_hook = 0;

Re: [PATCH] Hooks still needed for annotations

[Bob Rossi]

On Wed, Jun 01, 2005 at 07:15:45PM +1200, Nick Roberts wrote:
> 
> On 2004-04-21 the lines below were added to clear_interpreter_hooks in
> interps.c:
> 
>   deprecated_delete_breakpoint_hook = 0;
>   deprecated_modify_breakpoint_hook = 0;
> 
> Previously they were set to breakpoint_changed (a more natural name would be
> annotate_breakpoints_invalid).  This means that sometimes breakpoints-invalid
> annotations aren't generated. In particular this is the case when a breakpoint
> is toggled between its enabled state and disabled state.
> 
> Although the intention is to eventually remove annotations I don't think this
> stage has been reached yet and it makes little sense to remove a small
> number of calls. The patch below re-instates them.

Nick, in order for you to guarentee that your Emacs is working properly,
you are going to have to update the breakpoints after every command the
user types. Even though I think adding the patch is a good idea, if you
don't update the breakpoints after every command, bugs like this will
make it so that some users do not get the updated breakpoints.

For instance, make a small main program, add a breakpoint, and then
immediatly delete it. I doubt you will get the breakpoints-invalid
annotation. The problem is, even if you fix them, you still have to
check the breakpoints after every command unless you query GDB for it's
version number to see if the bug is fixed.

Bob Rossi

Re: [PATCH] Hooks still needed for annotations

[Nick Roberts]

 > > Although the intention is to eventually remove annotations I don't think
 > > this stage has been reached yet and it makes little sense to remove a
 > > small number of calls. The patch below re-instates them.
 > 
 > Nick, in order for you to guarentee that your Emacs is working properly,
 > you are going to have to update the breakpoints after every command the
 > user types. Even though I think adding the patch is a good idea, if you
 > don't update the breakpoints after every command, bugs like this will
 > make it so that some users do not get the updated breakpoints.

I don't think the fact that these annotations are missing in released versions
of GDB (6.2 and 6.3?) is a good reason not to have them in future releases.

 > For instance, make a small main program, add a breakpoint, and then
 > immediatly delete it. I doubt you will get the breakpoints-invalid
 > annotation. The problem is, even if you fix them, you still have to
 > check the breakpoints after every command unless you query GDB for it's
 > version number to see if the bug is fixed.

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.

Nick

Re: [PATCH] Hooks still needed for annotations

[Daniel Jacobowitz]

On Thu, Jun 02, 2005 at 09:32:31AM +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 didn't look in to the substance of the patch yet, just this
discussion.)

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [PATCH] Hooks still needed for annotations

[Nick Roberts]

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

In the past Andrew (Sat, 01 Mar 2003 21:37:33 -0500) has discriminated between
two types of annotations:

> - markups, as in the above marking up of the breakpoint out
> - events, as in things like `*stopped'

The general idea was that the former would go while the latter would stay.
Clearly breakpoints-invalid belongs to the latter.

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

Nick

Re: [PATCH] Hooks still needed for annotations

[Daniel Jacobowitz]

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

Re: [PATCH] Hooks still needed for annotations

[Nick Roberts]

 > The way to prevent them from being removed again is to add test cases.

OK, I've done this. Running the tests revealed a small bug with
 "set annotate" -- it didn't call _initialize_annotate to set the hooks.
This must be why the tests didn't fail when the hooks were removed in the
first place.

I've only tested for breakpoints-invalid annotations when breakpoints
have been deleted as I could simply adapt existing tests. They should
also be present when breakpoints are enabled/disabled. However, this test
should be sufficient to prevent the inadvertant removal of the hooks.

Nick


2005-06-04  Nick Roberts  <nickrob@snap.net.nz>

	* event-top.c (change_annotation_level): Call _initialize_annotate.

	* interps.c (clear_interpreter_hooks):
	Re-instate deprecated_delete_breakpoint_hook and
	deprecated_modify_breakpoint_hook for annotations.

2005-06-04  Nick Roberts  <nickrob@snap.net.nz>

	* gdb.base/annota1.exp, gdb.base/annota3.exp, gdb.cp/annota3.exp:
	Test for breakpoints-invalid when deleting breakpoints.


*** /home/nick/src/gdb/event-top.c.~1.40.~	2005-03-17 12:23:51.000000000 +1300
--- /home/nick/src/gdb/event-top.c	2005-06-04 14:36:37.000000000 +1200
***************
*** 43,48 ****
--- 43,50 ----
  /* readline defines this.  */
  #undef savestring
  
+ extern void _initialize_annotate (void);
+ 
  static void rl_callback_read_char_wrapper (gdb_client_data client_data);
  static void command_line_handler (char *rl);
  static void command_line_handler_continuation (struct continuation_arg *arg);
***************
*** 359,364 ****
--- 361,367 ----
  	  pop_prompt ();
  	}
      }
+   _initialize_annotate ();
  }
  
  /* Pushes a new prompt on the prompt stack. Each prompt has three


*** /home/nick/src/gdb/event-top.c.~1.40.~	2005-03-17 12:23:51.000000000 +1300
--- /home/nick/src/gdb/event-top.c	2005-06-04 14:36:37.000000000 +1200
***************
*** 43,48 ****
--- 43,50 ----
  /* readline defines this.  */
  #undef savestring
  
+ extern void _initialize_annotate (void);
+ 
  static void rl_callback_read_char_wrapper (gdb_client_data client_data);
  static void command_line_handler (char *rl);
  static void command_line_handler_continuation (struct continuation_arg *arg);
***************
*** 359,364 ****
--- 361,367 ----
  	  pop_prompt ();
  	}
      }
+   _initialize_annotate ();
  }
  
  /* Pushes a new prompt on the prompt stack. Each prompt has three


*** /home/nick/src/gdb/interps.c.~1.15.~	2005-04-26 21:44:15.000000000 +1200
--- /home/nick/src/gdb/interps.c	2005-06-04 15:12:16.000000000 +1200
***************
*** 326,333 ****
    deprecated_query_hook = 0;
    deprecated_warning_hook = 0;
    deprecated_create_breakpoint_hook = 0;
-   deprecated_delete_breakpoint_hook = 0;
-   deprecated_modify_breakpoint_hook = 0;
    deprecated_interactive_hook = 0;
    deprecated_registers_changed_hook = 0;
    deprecated_readline_begin_hook = 0;
--- 326,331 ----


*** /home/nick/src/gdb/testsuite/gdb.base/annota1.exp.~1.17.~	2005-04-28 17:17:24.000000000 +1200
--- /home/nick/src/gdb/testsuite/gdb.base/annota1.exp	2005-06-04 14:50:08.000000000 +1200
***************
*** 315,321 ****
  #
  send_gdb "delete 1\n"
  gdb_expect {
!      -re "\r\n\032\032post-prompt\r\n$gdb_prompt$" \
            { pass "delete bp 1" }
       -re ".*$gdb_prompt$"  { fail "delete bp 1" }
       timeout { fail "delete bp 1 (timeout)" }
--- 315,321 ----
  #
  send_gdb "delete 1\n"
  gdb_expect {
!      -re "\r\n\032\032post-prompt\r\n\r\n\032\032breakpoints-invalid\r\n$gdb_prompt$" \
            { pass "delete bp 1" }
       -re ".*$gdb_prompt$"  { fail "delete bp 1" }
       timeout { fail "delete bp 1 (timeout)" }
***************
*** 323,329 ****
  
  send_gdb "delete 2\n"
  gdb_expect {
!      -re "\r\n\032\032post-prompt\r\n$gdb_prompt$" \
  	     { pass "delete bp 2" }
       -re ".*$gdb_prompt$"  { fail "delete bp 2 " }
       timeout { fail "delete bp 2 (timeout)" }
--- 323,329 ----
  
  send_gdb "delete 2\n"
  gdb_expect {
!      -re "\r\n\032\032post-prompt\r\n\r\n\032\032breakpoints-invalid\r\n$gdb_prompt$" \
  	     { pass "delete bp 2" }
       -re ".*$gdb_prompt$"  { fail "delete bp 2 " }
       timeout { fail "delete bp 2 (timeout)" }
***************
*** 331,337 ****
  
  send_gdb "delete 3\n"
  gdb_expect {
!      -re "\r\n\032\032post-prompt\r\n$gdb_prompt$" \
  	     { pass "delete bp 3" }
       -re ".*$gdb_prompt$"  { fail "delete bp 3" }
       timeout { fail "delete bp 3 (timeout)" }
--- 331,337 ----
  
  send_gdb "delete 3\n"
  gdb_expect {
!      -re "\r\n\032\032post-prompt\r\n\r\n\032\032breakpoints-invalid\r\n$gdb_prompt$" \
  	     { pass "delete bp 3" }
       -re ".*$gdb_prompt$"  { fail "delete bp 3" }
       timeout { fail "delete bp 3 (timeout)" }


*** /home/nick/src/gdb/testsuite/gdb.base/annota3.exp.~1.5.~	2004-07-26 03:41:51.000000000 +1200
--- /home/nick/src/gdb/testsuite/gdb.base/annota3.exp	2005-06-04 14:45:03.000000000 +1200
***************
*** 258,273 ****
--- 258,276 ----
  send_gdb "delete 1\n"
  gdb_expect_list "delete bp 1" "$gdb_prompt$" {
      "\r\n\032\032post-prompt\r\n"
+     "\r\n\032\032breakpoints-invalid\r\n"
  }
  
  send_gdb "delete 2\n"
  gdb_expect_list "delete bp 2" "$gdb_prompt$" {
      "\r\n\032\032post-prompt\r\n"
+     "\r\n\032\032breakpoints-invalid\r\n"
  }
  
  send_gdb "delete 3\n"
  gdb_expect_list "delete bp 3" "$gdb_prompt$" {
      "\r\n\032\032post-prompt\r\n"
+     "\r\n\032\032breakpoints-invalid\r\n"
  }
  
  #


*** /home/nick/src/gdb/testsuite/gdb.cp/annota3.exp.~1.3.~	2004-02-28 09:23:12.000000000 +1300
--- /home/nick/src/gdb/testsuite/gdb.cp/annota3.exp	2005-06-04 14:56:46.000000000 +1200
***************
*** 140,146 ****
    -re ".*Delete all breakpoints. \\(y or n\\) \r\n\032\032query.*$" {
             send_gdb "y\n"
             gdb_expect {
! 	     -re "\r\n\032\032post-query\r\n$gdb_prompt$" { pass "delete bps" }
  	     -re ".*$gdb_prompt$" { fail "delete bps" }
  	     timeout  { fail "delete bps (timeout)" }
  	 }
--- 140,146 ----
    -re ".*Delete all breakpoints. \\(y or n\\) \r\n\032\032query.*$" {
             send_gdb "y\n"
             gdb_expect {
! 	     -re "\r\n\032\032post-query\r\n\r\n\032\032breakpoints-invalid\r\n$gdb_prompt$" { pass "delete bps" }
  	     -re ".*$gdb_prompt$" { fail "delete bps" }
  	     timeout  { fail "delete bps (timeout)" }
  	 }

Re: [PATCH] Hooks still needed for annotations

[Daniel Jacobowitz]

On Sat, Jun 04, 2005 at 03:18:55PM +1200, Nick Roberts wrote:
>  > The way to prevent them from being removed again is to add test cases.
> 
> OK, I've done this. Running the tests revealed a small bug with
>  "set annotate" -- it didn't call _initialize_annotate to set the hooks.
> This must be why the tests didn't fail when the hooks were removed in the
> first place.
> 
> I've only tested for breakpoints-invalid annotations when breakpoints
> have been deleted as I could simply adapt existing tests. They should
> also be present when breakpoints are enabled/disabled. However, this test
> should be sufficient to prevent the inadvertant removal of the hooks.

OK, having answered the rest of the side topics in this discussion I
now come to the actual patch...

Having reread the discussion I would like to ask you what your goal is
with this patch.  You don't use this annotation, and you've said that
it is very awkward to use because of the amount of output it produces.
Why should we fix it (as opposed to garbage collecting it) if no one
has missed it?

About the patch:

> *** /home/nick/src/gdb/event-top.c.~1.40.~	2005-03-17 12:23:51.000000000 +1300
> --- /home/nick/src/gdb/event-top.c	2005-06-04 14:36:37.000000000 +1200
> ***************
> *** 43,48 ****
> --- 43,50 ----
>   /* readline defines this.  */
>   #undef savestring
>   
> + extern void _initialize_annotate (void);
> + 
>   static void rl_callback_read_char_wrapper (gdb_client_data client_data);
>   static void command_line_handler (char *rl);
>   static void command_line_handler_continuation (struct continuation_arg *arg);

No extern prototypes.  If you need to call a function from another
file, it should be defined in a header, and the header should be
included in both the defining and using files.  That's the only way in
C we can make sure that argument mismatch does not creep in.  Also,
please move this into a new function if you want it to be called other
than from init.c; the _initialize_* functions are magic.

> *** /home/nick/src/gdb/interps.c.~1.15.~	2005-04-26 21:44:15.000000000 +1200
> --- /home/nick/src/gdb/interps.c	2005-06-04 15:12:16.000000000 +1200
> ***************
> *** 326,333 ****
>     deprecated_query_hook = 0;
>     deprecated_warning_hook = 0;
>     deprecated_create_breakpoint_hook = 0;
> -   deprecated_delete_breakpoint_hook = 0;
> -   deprecated_modify_breakpoint_hook = 0;
>     deprecated_interactive_hook = 0;
>     deprecated_registers_changed_hook = 0;
>     deprecated_readline_begin_hook = 0;
> --- 326,331 ----

deprecated_create_breakpoint_hook is now set nowhere.

deprecated_delete_breakpoint_hook and deprecated_modify_breakpoint_hook
are set only by annotations.  There's a total of three call sites
between the two hooks.  And each of those takes up more screen real
estate than a call to breakpoints_changed, which is what they
eventually become.

The comments in mention() suggest that at one time, GDB was trying to
move away from breakpoints_changed to a more specific set of hooks. 
But now the hooks are more or less dead, and to get full mileage out of
them they're going to need a redesign.  So maybe we should just delete
all three hooks, and replace the two that annotations use with
calls to breakpoints_changed.


-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [PATCH] Hooks still needed for annotations

[Nick Roberts]

 > Having reread the discussion I would like to ask you what your goal is
 > with this patch.  You don't use this annotation, and you've said that
 > it is very awkward to use because of the amount of output it produces.
 > Why should we fix it (as opposed to garbage collecting it) if no one
 > has missed it?

The original authors must have seen a need when they created these
annotations.  I was just being conservative because there hasn't been a
release of Emacs to test my code fully.

 > The comments in mention() suggest that at one time, GDB was trying to
 > move away from breakpoints_changed to a more specific set of hooks. 
 > But now the hooks are more or less dead, and to get full mileage out of
 > them they're going to need a redesign.  So maybe we should just delete
 > all three hooks, and replace the two that annotations use with
 > calls to breakpoints_changed.

Yes that looks a lot simpler.  If you are agreeable to me fixing it in the
first place, I will do that.

Nick

Re: [PATCH] Hooks still needed for annotations

[Daniel Jacobowitz]

On Mon, Jul 04, 2005 at 09:52:51AM +1200, Nick Roberts wrote:
>  > Having reread the discussion I would like to ask you what your goal is
>  > with this patch.  You don't use this annotation, and you've said that
>  > it is very awkward to use because of the amount of output it produces.
>  > Why should we fix it (as opposed to garbage collecting it) if no one
>  > has missed it?
> 
> The original authors must have seen a need when they created these
> annotations.  I was just being conservative because there hasn't been a
> release of Emacs to test my code fully.

But the need seems to have gone.  I just don't understand why you're
trying to fix it; you said you didn't use it, so how could your code
rely on it?

>  > The comments in mention() suggest that at one time, GDB was trying to
>  > move away from breakpoints_changed to a more specific set of hooks. 
>  > But now the hooks are more or less dead, and to get full mileage out of
>  > them they're going to need a redesign.  So maybe we should just delete
>  > all three hooks, and replace the two that annotations use with
>  > calls to breakpoints_changed.
> 
> Yes that looks a lot simpler.  If you are agreeable to me fixing it in the
> first place, I will do that.

Might as well, I suppose.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [PATCH] Hooks still needed for annotations

[Bob Rossi]

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

Re: [PATCH] Hooks still needed for annotations

[Daniel Jacobowitz]

On Sat, Jun 04, 2005 at 09:02:28AM -0400, Bob Rossi wrote:
> On Fri, Jun 03, 2005 at 07:59:24PM -0400, Daniel Jacobowitz wrote:
> > 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.

This bit has some logical sense on its own, but not in your examples.
Eclipse uses a hybrid GDB/CLI implementation - but not annotations (as
far as I know, anyway)!  Apple uses a patched GDB with substantially
different MI behavior - but not annotations (again, AFAIK)!

Feel free to correct me if I'm wrong, but those are not compelling
examples of why yet another output format should stick around.  The
fact that you and Nick are using them is a more compelling reason.

> 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)?

This is also unrelated to the removal of annotations.

I don't much think a parser is GDB's responsibility.  Offering one as a
convenience, sure, maybe.  Note that a lot of frontends won't get to
use it anyway!  If we ship it with GDB, then it's going to be covered
under the GPL.

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

Maybe it will need a format change.  But, guess what, it is still not
an asynchronous event.  We don't have a comprehensive story in place
for this sort of response yet.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [PATCH] Hooks still needed for annotations

[Bob Rossi]

On Sun, Jun 12, 2005 at 11:14:00PM -0400, Daniel Jacobowitz wrote:
> On Sat, Jun 04, 2005 at 09:02:28AM -0400, Bob Rossi wrote:
> > On Fri, Jun 03, 2005 at 07:59:24PM -0400, Daniel Jacobowitz wrote:
> > > 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.
> 
> This bit has some logical sense on its own, but not in your examples.
> Eclipse uses a hybrid GDB/CLI implementation - but not annotations (as
> far as I know, anyway)!  Apple uses a patched GDB with substantially
> different MI behavior - but not annotations (again, AFAIK)!

Hi Daniel,

Yes, you are right. I suppose the point I was trying to get across was
that GDB/MI is very good, but just not ready full time ready on it's
own. (Which we are changing rapidly)

> Feel free to correct me if I'm wrong, but those are not compelling
> examples of why yet another output format should stick around.  The
> fact that you and Nick are using them is a more compelling reason.

I agree with you.

> > 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)?
> 
> This is also unrelated to the removal of annotations.

I think that this could be related (although not a prerequisite) to the 
removal of annotations. Only in the sense that the annotations should 
stay until GDB/MI is fully mature. I do see your point though, I just 
have different motivations than you (I think).

> I don't much think a parser is GDB's responsibility.  Offering one as a
> convenience, sure, maybe.  Note that a lot of frontends won't get to
> use it anyway!  If we ship it with GDB, then it's going to be covered
> under the GPL.

Well, could I maintain a copy under the LGPL, and then contribute all of
the modifications to the FSF GDB under the GPL?

Either way, I don't care much about commercial tools. If a good parser
is created, I think it's possible a lot of front ends will use it. For
instance, KGDB, DDD and GVD are all free projects that could benefit
from such a technology. Right?

> > > - 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 
> 
> Maybe it will need a format change.  But, guess what, it is still not
> an asynchronous event.  We don't have a comprehensive story in place
> for this sort of response yet.

Yes, agreed.

Thanks,
Bob Rossi

Re: [PATCH] Hooks still needed for annotations

[Daniel Jacobowitz]

On Wed, Jun 15, 2005 at 11:52:48AM -0400, Bob Rossi wrote:
> > I don't much think a parser is GDB's responsibility.  Offering one as a
> > convenience, sure, maybe.  Note that a lot of frontends won't get to
> > use it anyway!  If we ship it with GDB, then it's going to be covered
> > under the GPL.
> 
> Well, could I maintain a copy under the LGPL, and then contribute all of
> the modifications to the FSF GDB under the GPL?

LGPL would not help much; you'd need something BSD-ish.  You could, of
course, do whatever you wanted to do with code that you wrote.  But I
don't think there's much point to that; if you contribute it to GDB,
that will be so that other developers can help you maintain it and keep
it up to date with changes in MI.  You won't get all the other GDB
contributors to relicense their work.

> Either way, I don't care much about commercial tools. If a good parser
> is created, I think it's possible a lot of front ends will use it. For
> instance, KGDB, DDD and GVD are all free projects that could benefit
> from such a technology. Right?

KGDB is a stub, not a frontend.  DDD could use it - not sure if
anyone's updating DDD enough nowadays to bother.  GVD could, but would
be unlikely to unless you wrote the parser in Ada!  (Not that Ada can't
use C bindings, but the GPS maintainers would presumably prefer
language consistency.)

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [PATCH] Hooks still needed for annotations

[Bob Rossi]

On Wed, Jun 15, 2005 at 12:07:49PM -0400, Daniel Jacobowitz wrote:
> On Wed, Jun 15, 2005 at 11:52:48AM -0400, Bob Rossi wrote:
> > > I don't much think a parser is GDB's responsibility.  Offering one as a
> > > convenience, sure, maybe.  Note that a lot of frontends won't get to
> > > use it anyway!  If we ship it with GDB, then it's going to be covered
> > > under the GPL.
> > 
> > Well, could I maintain a copy under the LGPL, and then contribute all of
> > the modifications to the FSF GDB under the GPL?
> 
> LGPL would not help much; you'd need something BSD-ish.  You could, of
> course, do whatever you wanted to do with code that you wrote.  But I
> don't think there's much point to that; if you contribute it to GDB,
> that will be so that other developers can help you maintain it and keep
> it up to date with changes in MI.  You won't get all the other GDB
> contributors to relicense their work.

O Right. Sorry to even bring it up. What is the stand of the FSF
regarding an LGPL library? and why do you think that the parser would 
have to be under a more academic license instead of a reciprocal
license?

> > Either way, I don't care much about commercial tools. If a good parser
> > is created, I think it's possible a lot of front ends will use it. For
> > instance, KGDB, DDD and GVD are all free projects that could benefit
> > from such a technology. Right?
> 
> KGDB is a stub, not a frontend.  DDD could use it - not sure if
> anyone's updating DDD enough nowadays to bother.  GVD could, but would
> be unlikely to unless you wrote the parser in Ada!  (Not that Ada can't
> use C bindings, but the GPS maintainers would presumably prefer
> language consistency.)

Well, I already have planned a way to translate the parse tree into Tcl.
I am going to walk the parse tree and then build up a Native Tcl parse
tree using callbacks. By doing this, I can write testcase's in Tcl using 
the parse tree. This would really allow for a much higher level of testing.
The ADA developers could use the exact same approach and it would be much 
more trivial for them to do so.

I'm getting a vibe from you that you think writing a parser could be a
bad idea. Do you really think that the community wouldn't embrace such a
parser? The whole reason I decided to create it (or at least in the
works) is because I was frustrated with the thought of writing yet
another low level parser to parse the MI. I just wanted one that worked,
and worked well. Even more than that, I wanted one that I didn't have to
constantly maintain. I mean, Nick and I are already going to create 
two different parsers. As things evolve, and the parser's need to work
with old versions of GDB, different bugs will pop up in each. I think
this hurts GDB in the long run. I also firmly think that the
only possible way to get a stable MI parser is to test it in GDB's
testsuite.

Thanks,
Bob Rossi

Re: [PATCH] Hooks still needed for annotations

[Daniel Jacobowitz]

On Wed, Jun 15, 2005 at 12:31:47PM -0400, Bob Rossi wrote:
> Well, I already have planned a way to translate the parse tree into Tcl.
> I am going to walk the parse tree and then build up a Native Tcl parse
> tree using callbacks. By doing this, I can write testcase's in Tcl using 
> the parse tree. This would really allow for a much higher level of testing.
> The ADA developers could use the exact same approach and it would be much 
> more trivial for them to do so.
> 
> I'm getting a vibe from you that you think writing a parser could be a
> bad idea. Do you really think that the community wouldn't embrace such a
> parser? The whole reason I decided to create it (or at least in the
> works) is because I was frustrated with the thought of writing yet
> another low level parser to parse the MI. I just wanted one that worked,
> and worked well. Even more than that, I wanted one that I didn't have to
> constantly maintain. I mean, Nick and I are already going to create 
> two different parsers. As things evolve, and the parser's need to work
> with old versions of GDB, different bugs will pop up in each. I think
> this hurts GDB in the long run. I also firmly think that the
> only possible way to get a stable MI parser is to test it in GDB's
> testsuite.

In GDB's testsuite it tests against the current versions of GDB, so
obviously if you want it to work with old GDBs then that isn't enough
testing to be useful.

I don't much care whether you write a reusable parser or not.  I'm
skeptical that it should be maintained as a part of the GDB
distribution, with the intention for other projects to import it from
GDB.  If it's part of GDB, then it's going to be GPL, which will
restrict its use.  If it's not part of GDB, then GDB developers aren't
going to update it.  Pick your poison... I don't know which I think
would be a better idea, yet.  I haven't thought about it much.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [PATCH] Hooks still needed for annotations

[Nick Roberts]

 > > > 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)?
 > > 
 > > This is also unrelated to the removal of annotations.
 > 
 > I think that this could be related (although not a prerequisite) to the 
 > removal of annotations. Only in the sense that the annotations should 
 > stay until GDB/MI is fully mature. I do see your point though, I just 
 > have different motivations than you (I think).

AFAIK the other frontends just use the one annotation, through the option
-fullname or -annotate=1.

Nick

Re: [PATCH] Hooks still needed for annotations

[Bob Rossi]

On Thu, Jun 16, 2005 at 11:08:15AM +1200, Nick Roberts wrote:
>  > > > 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)?
>  > > 
>  > > This is also unrelated to the removal of annotations.
>  > 
>  > I think that this could be related (although not a prerequisite) to the 
>  > removal of annotations. Only in the sense that the annotations should 
>  > stay until GDB/MI is fully mature. I do see your point though, I just 
>  > have different motivations than you (I think).
> 
> AFAIK the other frontends just use the one annotation, through the option
> -fullname or -annotate=1.

Right, I agree. However, with GDB/MI there is a compelling reason to
upgrade. I'm assuming that upgrading to MI would be essential to compete
functionaly with FE's like Emacs/Apple/Eclipse/CGDB. 

Bob Rossi

Re: [PATCH] Hooks still needed for annotations

[Bob Rossi]

> > 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)?
> 
> This is also unrelated to the removal of annotations.
> 
> I don't much think a parser is GDB's responsibility.  Offering one as a
> convenience, sure, maybe.  Note that a lot of frontends won't get to
> use it anyway!  If we ship it with GDB, then it's going to be covered
> under the GPL.

The more I think of it, the more I feel that I am correct on this. Even
if the parser was under the GPL, proprietary projects (Apple?) could
simply use the parse tree to translate the data into a nice format of
there own (XML?) and then communicate that to a parser thats linked into
there application. This type of solution would allow a closed source
company to get the benefits of an MI parser/semantical analyzer,
contribute to the project, and not have to think 1 second about low
level MI stuff in there FE.

Bob Rossi

Re: [PATCH] Hooks still needed for annotations

[Nick Roberts]

Bob Rossi writes:
 > > I don't much think a parser is GDB's responsibility.  Offering one as a
 > > convenience, sure, maybe.  Note that a lot of frontends won't get to
 > > use it anyway!  If we ship it with GDB, then it's going to be covered
 > > under the GPL.
 > 
 > The more I think of it, the more I feel that I am correct on this. Even
 > if the parser was under the GPL, proprietary projects (Apple?) could
 > simply use the parse tree to translate the data into a nice format of
 > there own (XML?) and then communicate that to a parser thats linked into
 > there application. This type of solution would allow a closed source
 > company to get the benefits of an MI parser/semantical analyzer,
 > contribute to the project, and not have to think 1 second about low
 > level MI stuff in there FE.

Bob,

You're quoting Daniel (I think), not me.  I must say though, that I don't see
an immediate need for a parser.  We can dictate the MI output.  Why not just
get that to play nice?

Nick

Re: [PATCH] Hooks still needed for annotations

[Nick Roberts]

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

Then lets try to remove the ones that can go.  In 2003 Andrew introduced
level 3 annotations as a subset of level 2 (with the markup annotations
left out).  Since then I have been using those quite happily with Emacs.

So, as far as Emacs is concerned, the annotations that are restricted to
level 2 in annotate.c, and this must be over half of them, can go.

Bob is this also the case for CGDB?

Emacs doesn't use breakpoints-invalid or frames-invalid either and they
spew out so often that it makes it hard to interrupt the inferior.  However
I would like to keep them for the moment, as they provide clues as to where
to put code for event nortification in MI.  Perhaps these could be restricted
to level 2.


Nick

Re: [PATCH] Hooks still needed for annotations

[Bob Rossi]

On Tue, Jun 07, 2005 at 09:57:48AM +1200, Nick Roberts wrote:
> 
>  > 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.
> 
> Then lets try to remove the ones that can go.  In 2003 Andrew introduced
> level 3 annotations as a subset of level 2 (with the markup annotations
> left out).  Since then I have been using those quite happily with Emacs.
> 
> So, as far as Emacs is concerned, the annotations that are restricted to
> level 2 in annotate.c, and this must be over half of them, can go.
> 
> Bob is this also the case for CGDB?

I could look and see what annotations CGDB uses. Would this be helpful?
I think it's only a handful.

> Emacs doesn't use breakpoints-invalid or frames-invalid either and they
> spew out so often that it makes it hard to interrupt the inferior.  However
> I would like to keep them for the moment, as they provide clues as to where
> to put code for event nortification in MI.  Perhaps these could be restricted
> to level 2.

I still use level 2, and personally thought introducing level 3 was a
really bad idea. Do you already use level 3, or could we simply just
start stripping down level 2?

Thanks,
Bob Rossi

Re: [PATCH] Hooks still needed for annotations

[Nick Roberts]

Bob Rossi writes:
 > On Tue, Jun 07, 2005 at 09:57:48AM +1200, Nick Roberts wrote:
 > > 
 > >  > 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.
 > > 
 > > Then lets try to remove the ones that can go.  In 2003 Andrew introduced
 > > level 3 annotations as a subset of level 2 (with the markup annotations
 > > left out).  Since then I have been using those quite happily with Emacs.
 > > 
 > > So, as far as Emacs is concerned, the annotations that are restricted to
 > > level 2 in annotate.c, and this must be over half of them, can go.
 > > 
 > > Bob is this also the case for CGDB?
 > 
 > I could look and see what annotations CGDB uses. Would this be helpful?
 > I think it's only a handful.

Well there hasn't been any interest shown from the global maintainers, but I
think it would be helpful. Do you need any of the annotations that are
not generated by level 3 annotations?  (Specified by
if (annotation_level == 2)... in annotate.c)

 > > Emacs doesn't use breakpoints-invalid or frames-invalid either and they
 > > spew out so often that it makes it hard to interrupt the inferior.  However
 > > I would like to keep them for the moment, as they provide clues as to where
 > > to put code for event nortification in MI.  Perhaps these could be restricted
 > > to level 2.
 > 
 > I still use level 2, and personally thought introducing level 3 was a
 > really bad idea.

Why is it a bad idea?

 > Do you already use level 3, or could we simply just start stripping down
 > level 2?

Keeping level 3 allows a transition stage, I would now like to use it for
breakpoints-invalid and frames-invalid as stated above, in case I suddenly
find that Emacs does need them.

Nick

Re: [PATCH] Hooks still needed for annotations

[Bob Rossi]

On Fri, Jun 10, 2005 at 03:26:34PM +1200, Nick Roberts wrote:
> Bob Rossi writes:
>  > On Tue, Jun 07, 2005 at 09:57:48AM +1200, Nick Roberts wrote:
>  > > 
>  > >  > 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.
>  > > 
>  > > Then lets try to remove the ones that can go.  In 2003 Andrew introduced
>  > > level 3 annotations as a subset of level 2 (with the markup annotations
>  > > left out).  Since then I have been using those quite happily with Emacs.
>  > > 
>  > > So, as far as Emacs is concerned, the annotations that are restricted to
>  > > level 2 in annotate.c, and this must be over half of them, can go.
>  > > 
>  > > Bob is this also the case for CGDB?
>  > 
>  > I could look and see what annotations CGDB uses. Would this be helpful?
>  > I think it's only a handful.
> 
> Well there hasn't been any interest shown from the global maintainers, but I
> think it would be helpful. Do you need any of the annotations that are
> not generated by level 3 annotations?  (Specified by
> if (annotation_level == 2)... in annotate.c)

Sorry about the delay, here is the list of annotations I use/don't use.

"source",                   handle_source

"pre-commands",             handle_misc_pre_prompt
"commands",                 handle_misc_prompt
"post-commands",            handle_misc_post_prompt

"pre-overload-choice",      handle_misc_pre_prompt
"overload-choice",          handle_misc_prompt
"post-overload-choice",     handle_misc_post_prompt

"pre-query",                handle_misc_pre_prompt
"query",                    handle_misc_prompt
"post-query",               handle_misc_post_prompt

"pre-prompt-for-continue",  handle_misc_pre_prompt
"prompt-for-continue",      handle_misc_prompt
"post-prompt-for-continue", handle_misc_post_prompt

"pre-prompt",               handle_pre_prompt
"prompt",                   handle_prompt
"post-prompt",              handle_post_prompt

"breakpoints-headers",      handle_breakpoints_headers
"breakpoints-table-end",    handle_breakpoints_table_end
"breakpoints-table",        handle_breakpoints_table

"breakpoints-invalid",      NOT_SUPPORTED
"value-history-begin",      NOT_SUPPORTED
"value-history-value",      NOT_SUPPORTED
"value-history-end",        NOT_SUPPORTED
"value-begin",              NOT_SUPPORTED
"value-end",                NOT_SUPPORTED
"arg-begin",                NOT_SUPPORTED
"arg-name-end",             NOT_SUPPORTED
"arg-value",                NOT_SUPPORTED
"arg-end",                  NOT_SUPPORTED
"field-begin",              NOT_SUPPORTED
"field-name-end",           NOT_SUPPORTED
"field-value",              NOT_SUPPORTED
"field-end",                NOT_SUPPORTED

"field",                    handle_field
"record",                   handle_record
"error-begin",              handle_error_begin
"error",                    handle_error
"exited",                   handle_exited
"quit",                     handle_quit

"display-begin",            NOT_SUPPORTED
"display-number-end",       NOT_SUPPORTED
"display-format",           NOT_SUPPORTED
"display-expression",       NOT_SUPPORTED
"display-expression-end",   NOT_SUPPORTED
"display-value",            NOT_SUPPORTED


If it says, NOT_SUPPORTED then I don't use them. Otherwise I do. I
showed you the semantics behind the annotation also. For instance, all
of the pre,*,post commands could be changed to pre-query, 
query, post-query and CGDB would continue to work just fine.

Of course, any that I haven't listed, CGDB doesn't use either.

>  > > Emacs doesn't use breakpoints-invalid or frames-invalid either and they
>  > > spew out so often that it makes it hard to interrupt the inferior.  However
>  > > I would like to keep them for the moment, as they provide clues as to where
>  > > to put code for event nortification in MI.  Perhaps these could be restricted
>  > > to level 2.
>  > 
>  > I still use level 2, and personally thought introducing level 3 was a
>  > really bad idea.
> 
> Why is it a bad idea?

Well, it goes back to making CGDB more complicated. For example, CGDB
works with just about any version of GDB. (even 5-7 years old).

However, once you go to annotate level 3, now CGDB will have to detect
the version of annotations that GDB supports. This makes things
unnecessarily more complicated. Why not just get rid of annotate 3, and
slowly remove features from annotate 2?

>  > Do you already use level 3, or could we simply just start stripping down
>  > level 2?
> 
> Keeping level 3 allows a transition stage, I would now like to use it for
> breakpoints-invalid and frames-invalid as stated above, in case I suddenly
> find that Emacs does need them.

Well breakpoints-invalid and frames-invalid already work (kind of) in 
a2.  There is no reason to deprecate a2 and then get the same
functionality in a3. (Although I might be missing something?). I really
think that adding an a3 interface is a real bad idea.

Thanks,
Bob Rossi

Re: [PATCH] Hooks still needed for annotations

[Nick Roberts]

 > >  > > So, as far as Emacs is concerned, the annotations that are
 > >  > > restricted to level 2 in annotate.c, and this must be over half of
 > >  > > them, can go.
 > >  > > 
 > >  > > Bob is this also the case for CGDB?
 > >  > 
 > >  > I could look and see what annotations CGDB uses. Would this be helpful?
 > >  > I think it's only a handful.
 > > 
 > > Well there hasn't been any interest shown from the global maintainers,
 > > but I think it would be helpful. Do you need any of the annotations that
 > > are not generated by level 3 annotations?  (Specified by if
 > > (annotation_level == 2)... in annotate.c)
 > 
 > Sorry about the delay, here is the list of annotations I use/don't use.
 ...

Thanks

 > >  > > Emacs doesn't use breakpoints-invalid or frames-invalid either and
 > >  > > they spew out so often that it makes it hard to interrupt the
 > >  > > inferior.  However I would like to keep them for the moment, as they
 > >  > > provide clues as to where to put code for event nortification in MI.
 > >  > > Perhaps these could be restricted to level 2.
 > >  > 
 > >  > I still use level 2, and personally thought introducing level 3 was a
 > >  > really bad idea.
 > > 
 > > Why is it a bad idea?
 > 
 > Well, it goes back to making CGDB more complicated. For example, CGDB
 > works with just about any version of GDB. (even 5-7 years old).
 > 
 > However, once you go to annotate level 3, now CGDB will have to detect
 > the version of annotations that GDB supports. This makes things
 > unnecessarily more complicated. Why not just get rid of annotate 3, and
 > slowly remove features from annotate 2?

Level 3 exists alongside level 2 and is a subset.  CGDB doesn't even have
to know about it.  I'd like to keep it for the reason I've already given
- to allow a transitions stage - it has (almost) no overhead.

 > >  > Do you already use level 3, or could we simply just start stripping down
 > >  > level 2?
 > > 
 > > Keeping level 3 allows a transition stage, I would now like to use it for
 > > breakpoints-invalid and frames-invalid as stated above, in case I suddenly
 > > find that Emacs does need them.
 > 
 > Well breakpoints-invalid and frames-invalid already work (kind of) in 
 > a2.  There is no reason to deprecate a2 and then get the same
 > functionality in a3. (Although I might be missing something?). I really
 > think that adding an a3 interface is a real bad idea.

Level 3 has a reduced functionality.  You've already said you think its a bad
idea, I'm trying to explain why I don't agree.  I'm not adding it, its
already there.

Nick

Re: [PATCH] Hooks still needed for annotations

[Bob Rossi]

On Thu, Jun 16, 2005 at 09:39:08AM +1200, Nick Roberts wrote:
>  > >  > > So, as far as Emacs is concerned, the annotations that are
>  > >  > > restricted to level 2 in annotate.c, and this must be over half of
>  > >  > > them, can go.
>  > >  > > 
>  > >  > > Bob is this also the case for CGDB?
>  > >  > 
>  > >  > I could look and see what annotations CGDB uses. Would this be helpful?
>  > >  > I think it's only a handful.
>  > > 
>  > > Well there hasn't been any interest shown from the global maintainers,
>  > > but I think it would be helpful. Do you need any of the annotations that
>  > > are not generated by level 3 annotations?  (Specified by if
>  > > (annotation_level == 2)... in annotate.c)
>  > 
>  > Sorry about the delay, here is the list of annotations I use/don't use.
>  ...
> 
> Thanks
> 
>  > >  > > Emacs doesn't use breakpoints-invalid or frames-invalid either and
>  > >  > > they spew out so often that it makes it hard to interrupt the
>  > >  > > inferior.  However I would like to keep them for the moment, as they
>  > >  > > provide clues as to where to put code for event nortification in MI.
>  > >  > > Perhaps these could be restricted to level 2.
>  > >  > 
>  > >  > I still use level 2, and personally thought introducing level 3 was a
>  > >  > really bad idea.
>  > > 
>  > > Why is it a bad idea?
>  > 
>  > Well, it goes back to making CGDB more complicated. For example, CGDB
>  > works with just about any version of GDB. (even 5-7 years old).
>  > 
>  > However, once you go to annotate level 3, now CGDB will have to detect
>  > the version of annotations that GDB supports. This makes things
>  > unnecessarily more complicated. Why not just get rid of annotate 3, and
>  > slowly remove features from annotate 2?
> 
> Level 3 exists alongside level 2 and is a subset.  CGDB doesn't even have
> to know about it.  I'd like to keep it for the reason I've already given
> - to allow a transitions stage - it has (almost) no overhead.

OK.
>  > >  > Do you already use level 3, or could we simply just start stripping down
>  > >  > level 2?
>  > > 
>  > > Keeping level 3 allows a transition stage, I would now like to use it for
>  > > breakpoints-invalid and frames-invalid as stated above, in case I suddenly
>  > > find that Emacs does need them.
>  > 
>  > Well breakpoints-invalid and frames-invalid already work (kind of) in 
>  > a2.  There is no reason to deprecate a2 and then get the same
>  > functionality in a3. (Although I might be missing something?). I really
>  > think that adding an a3 interface is a real bad idea.
> 
> Level 3 has a reduced functionality.  You've already said you think its a bad
> idea, I'm trying to explain why I don't agree.  I'm not adding it, its
> already there.

OK. Thanks for keeping me up to speed. I was under the impression that
level 2 was going to go away completly and level 3 would be the
temporary replacement. If level 2 stays (even though it's reduced), it
would be completly fine with me.

Thanks,
Bob Rossi

Re: [PATCH] Hooks still needed for annotations

[Daniel Jacobowitz]

On Wed, Jun 15, 2005 at 06:57:59PM -0400, Bob Rossi wrote:
> >  > >  > Do you already use level 3, or could we simply just start stripping down
> >  > >  > level 2?

The point of introducing level 3 - a stripped down version of level 2 -
was to transition clients to using it and then discard level 2, instead
of having to find everyone using annotations and work out whether we
broke them every time someone wants to strip something out of level 2. 
When everyone we care about is happy with level 3, we can kill level 2.

Bob, sometimes I feel like you pick very strange things to label as
"hard".  What's hard about autodetecting the availability of annotate
level 3?  Or even doing it based on version number?

> >  > > Keeping level 3 allows a transition stage, I would now like to use it for
> >  > > breakpoints-invalid and frames-invalid as stated above, in case I suddenly
> >  > > find that Emacs does need them.
> >  > 
> >  > Well breakpoints-invalid and frames-invalid already work (kind of) in 
> >  > a2.  There is no reason to deprecate a2 and then get the same
> >  > functionality in a3. (Although I might be missing something?). I really
> >  > think that adding an a3 interface is a real bad idea.
> > 
> > Level 3 has a reduced functionality.  You've already said you think its a bad
> > idea, I'm trying to explain why I don't agree.  I'm not adding it, its
> > already there.
> 
> OK. Thanks for keeping me up to speed. I was under the impression that
> level 2 was going to go away completly and level 3 would be the
> temporary replacement. If level 2 stays (even though it's reduced), it
> would be completly fine with me.

Annotations are going to go away.  Period.  Not yet - not until we
agree that MI is ready - but I expect level 2 to go away before level
3.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [PATCH] Hooks still needed for annotations

[Bob Rossi]

On Sun, Jul 03, 2005 at 12:39:16PM -0400, Daniel Jacobowitz wrote:
> On Wed, Jun 15, 2005 at 06:57:59PM -0400, Bob Rossi wrote:
> > >  > >  > Do you already use level 3, or could we simply just start stripping down
> > >  > >  > level 2?
> 
> The point of introducing level 3 - a stripped down version of level 2 -
> was to transition clients to using it and then discard level 2, instead
> of having to find everyone using annotations and work out whether we
> broke them every time someone wants to strip something out of level 2. 
> When everyone we care about is happy with level 3, we can kill level 2.
> 
> Bob, sometimes I feel like you pick very strange things to label as
> "hard".  What's hard about autodetecting the availability of annotate
> level 3?  Or even doing it based on version number?

I just simply can't stand the thought of starting up GDB several times
to determine what the correct protocol the FE should use. This
doesn't seem necessary. Also, using the version number is strange, at
best. GDB is released at midpoint on a usual basis on many distro's.
Determining if GDB supports certain features by version number is not
accurately possible to do.

I submitted a patch a while back, that was related to MI. It was
supposed to allow a FE to handshake with GDB to determine the protocol
to use. I have a much simpler idea. Why don't I write up a patch that
would work like so,

gdb -i=mi2,a2,a3 ...
protocol=mi2
...

Basically, you could pass in an arbitrary amount of protocols that the
FE supports, in the order the FE would like to communicate. The first
thing GDB will print is the protocol it supports and will use. From then
on, everything is like normal.

Bob Rossi

Re: [PATCH] Hooks still needed for annotations

[Daniel Jacobowitz]

On Wed, Jul 06, 2005 at 11:03:33AM -0400, Bob Rossi wrote:
> On Sun, Jul 03, 2005 at 12:39:16PM -0400, Daniel Jacobowitz wrote:
> > On Wed, Jun 15, 2005 at 06:57:59PM -0400, Bob Rossi wrote:
> > > >  > >  > Do you already use level 3, or could we simply just start stripping down
> > > >  > >  > level 2?
> > 
> > The point of introducing level 3 - a stripped down version of level 2 -
> > was to transition clients to using it and then discard level 2, instead
> > of having to find everyone using annotations and work out whether we
> > broke them every time someone wants to strip something out of level 2. 
> > When everyone we care about is happy with level 3, we can kill level 2.
> > 
> > Bob, sometimes I feel like you pick very strange things to label as
> > "hard".  What's hard about autodetecting the availability of annotate
> > level 3?  Or even doing it based on version number?
> 
> I just simply can't stand the thought of starting up GDB several times
> to determine what the correct protocol the FE should use. This
> doesn't seem necessary.

But it's _simpler_ than any of this complicated handshaking, or even
the revised -i option you suggested below.  Just start GDB with the
interface you want it to use.  If it doesn't recognize it, it will
quickly and clearly tell you so.

drow@nevyn:~% gdb -i=mi4
Interpreter `mi4' unrecognized

-- 
Daniel Jacobowitz
CodeSourcery, LLC