[rfc] Annotation level THREE

[rfc] Annotation level THREE

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 494 bytes --]

To follow through a discussion on gdb@ this patch adds annotation level 
three to the GDB sources.

Annotation level three:

- keeps the event notifications from annotation level two
- removes all the output markups

The assumption being that the client can use the more robust 
`interpreter mi ...' instead of those obnoxus[sp] markups.

comments?

Yes, this will mean a major revision of the documentation.

With this and its doco in, I think 5.4 is clear to go (or at least try to).

Andrew

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 15353 bytes --]

2003-03-11  Andrew Cagney  <cagney@redhat.com>

	* annotate.c: Update copyright.
	(annotate_signal_name): Restrict annotation to level 2.
	(annotate_breakpoints_headers, annotate_signal_name_end): Ditto.
	(annotate_signal_string, annotate_signal_string_end): Ditto.
	(annotate_field, annotate_breakpoints_table): Ditto.
	(annotate_record, annotate_breakpoints_table_end): Ditto.
	(annotate_field_begin, annotate_field_name_end): Ditto.
	(annotate_field_end, annotate_field_value): Ditto.
	(annotate_error_begin, annotate_value_history_begin): Ditto.
	(annotate_value_begin, annotate_value_history_value): Ditto.
	(annotate_value_history_end, annotate_value_end): Ditto.
	(annotate_display_begin, annotate_display_number_end): Ditto.
	(annotate_display_format, annotate_display_expression): Ditto.
	(annotate_display_expression_end, annotate_display_value): Ditto.
	(annotate_display_end, annotate_arg_begin): Ditto.
	(annotate_arg_name_end, annotate_arg_value): Ditto.
	(annotate_arg_end, annotate_source): Ditto.
	(annotate_frame_begin, annotate_function_call): Ditto.
	(annotate_signal_handler_caller, annotate_frame_address): Ditto.
	(annotate_frame_address_end, annotate_frame_function_name): Ditto.
	(annotate_frame_args, annotate_frame_source_begin): Ditto.
	(annotate_frame_source_file, annotate_frame_source_file_end): Ditto.
	(annotate_frame_source_line, annotate_frame_source_end): Ditto.
	(annotate_frame_where, annotate_frame_end): Ditto.
	(annotate_array_section_begin, annotate_elt_rep): Ditto.
	(annotate_elt_rep_end, annotate_elt): Ditto.
	(annotate_array_section_end): Ditto.
	* top.c (command_line_input): Ditto.
	* event-top.c (change_annotation_level): Ditto.
	(command_line_handler): Ditto.
	* utils.c (query, rompt_for_continue): Ditto.

Index: annotate.c
===================================================================
RCS file: /cvs/src/src/gdb/annotate.c,v
retrieving revision 1.5
diff -u -r1.5 annotate.c
--- annotate.c	6 Mar 2001 08:21:05 -0000	1.5
+++ annotate.c	11 Mar 2003 23:28:51 -0000
@@ -1,6 +1,7 @@
 /* Annotation routines for GDB.
-   Copyright 1986, 1989, 1990, 1991, 1992, 1994, 1995, 1996, 1998, 1999,
-   2000 Free Software Foundation, Inc.
+
+   Copyright 1986, 1989, 1990, 1991, 1992, 1994, 1995, 1996, 1998,
+   1999, 2000, 2003 Free Software Foundation, Inc.
 
    This file is part of GDB.
 
@@ -155,28 +156,28 @@
 void
 annotate_signal_name (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032signal-name\n");
 }
 
 void
 annotate_signal_name_end (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032signal-name-end\n");
 }
 
 void
 annotate_signal_string (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032signal-string\n");
 }
 
 void
 annotate_signal_string_end (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032signal-string-end\n");
 }
 
@@ -193,35 +194,35 @@
 void
 annotate_breakpoints_headers (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032breakpoints-headers\n");
 }
 
 void
 annotate_field (int num)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032field %d\n", num);
 }
 
 void
 annotate_breakpoints_table (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032breakpoints-table\n");
 }
 
 void
 annotate_record (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032record\n");
 }
 
 void
 annotate_breakpoints_table_end (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032breakpoints-table-end\n");
 }
 
@@ -238,7 +239,7 @@
 void
 annotate_field_begin (struct type *type)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     {
       printf_filtered ("\n\032\032field-begin ");
       print_value_flags (type);
@@ -249,21 +250,21 @@
 void
 annotate_field_name_end (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032field-name-end\n");
 }
 
 void
 annotate_field_value (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032field-value\n");
 }
 
 void
 annotate_field_end (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032field-end\n");
 }
 \f
@@ -284,14 +285,14 @@
 void
 annotate_error_begin (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     fprintf_filtered (gdb_stderr, "\n\032\032error-begin\n");
 }
 
 void
 annotate_value_history_begin (int histindex, struct type *type)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     {
       printf_filtered ("\n\032\032value-history-begin %d ", histindex);
       print_value_flags (type);
@@ -302,7 +303,7 @@
 void
 annotate_value_begin (struct type *type)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     {
       printf_filtered ("\n\032\032value-begin ");
       print_value_flags (type);
@@ -313,91 +314,91 @@
 void
 annotate_value_history_value (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032value-history-value\n");
 }
 
 void
 annotate_value_history_end (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032value-history-end\n");
 }
 
 void
 annotate_value_end (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032value-end\n");
 }
 
 void
 annotate_display_begin (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032display-begin\n");
 }
 
 void
 annotate_display_number_end (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032display-number-end\n");
 }
 
 void
 annotate_display_format (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032display-format\n");
 }
 
 void
 annotate_display_expression (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032display-expression\n");
 }
 
 void
 annotate_display_expression_end (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032display-expression-end\n");
 }
 
 void
 annotate_display_value (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032display-value\n");
 }
 
 void
 annotate_display_end (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032display-end\n");
 }
 
 void
 annotate_arg_begin (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032arg-begin\n");
 }
 
 void
 annotate_arg_name_end (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032arg-name-end\n");
 }
 
 void
 annotate_arg_value (struct type *type)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     {
       printf_filtered ("\n\032\032arg-value ");
       print_value_flags (type);
@@ -408,14 +409,16 @@
 void
 annotate_arg_end (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032arg-end\n");
 }
 
 void
 annotate_source (char *filename, int line, int character, int mid, CORE_ADDR pc)
 {
-  if (annotation_level > 1)
+  if (annotation_level > 2)
+    return;
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032source ");
   else
     printf_filtered ("\032\032");
@@ -430,7 +433,7 @@
 void
 annotate_frame_begin (int level, CORE_ADDR pc)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     {
       printf_filtered ("\n\032\032frame-begin %d 0x", level);
       print_address_numeric (pc, 0, gdb_stdout);
@@ -441,98 +444,98 @@
 void
 annotate_function_call (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032function-call\n");
 }
 
 void
 annotate_signal_handler_caller (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032signal-handler-caller\n");
 }
 
 void
 annotate_frame_address (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032frame-address\n");
 }
 
 void
 annotate_frame_address_end (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032frame-address-end\n");
 }
 
 void
 annotate_frame_function_name (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032frame-function-name\n");
 }
 
 void
 annotate_frame_args (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032frame-args\n");
 }
 
 void
 annotate_frame_source_begin (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032frame-source-begin\n");
 }
 
 void
 annotate_frame_source_file (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032frame-source-file\n");
 }
 
 void
 annotate_frame_source_file_end (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032frame-source-file-end\n");
 }
 
 void
 annotate_frame_source_line (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032frame-source-line\n");
 }
 
 void
 annotate_frame_source_end (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032frame-source-end\n");
 }
 
 void
 annotate_frame_where (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032frame-where\n");
 }
 
 void
 annotate_frame_end (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032frame-end\n");
 }
 \f
 void
 annotate_array_section_begin (int index, struct type *elttype)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     {
       printf_filtered ("\n\032\032array-section-begin %d ", index);
       print_value_flags (elttype);
@@ -543,28 +546,28 @@
 void
 annotate_elt_rep (unsigned int repcount)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032elt-rep %u\n", repcount);
 }
 
 void
 annotate_elt_rep_end (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032elt-rep-end\n");
 }
 
 void
 annotate_elt (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032elt\n");
 }
 
 void
 annotate_array_section_end (void)
 {
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032array-section-end\n");
 }
 
Index: event-top.c
===================================================================
RCS file: /cvs/src/src/gdb/event-top.c,v
retrieving revision 1.26
diff -u -r1.26 event-top.c
--- event-top.c	12 Feb 2003 15:31:30 -0000	1.26
+++ event-top.c	11 Mar 2003 23:28:51 -0000
@@ -325,7 +325,7 @@
       return;
     }
 
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     {
       if (!strcmp (PREFIX (0), "") && !strcmp (SUFFIX (0), ""))
 	{
@@ -613,7 +613,7 @@
 
   int repeat = (instream == stdin);
 
-  if (annotation_level > 1 && instream == stdin)
+  if (annotation_level == 2 && instream == stdin)
     {
       printf_unfiltered ("\n\032\032post-");
       printf_unfiltered (async_annotation_suffix);
Index: top.c
===================================================================
RCS file: /cvs/src/src/gdb/top.c,v
retrieving revision 1.71
diff -u -r1.71 top.c
--- top.c	6 Feb 2003 01:19:12 -0000	1.71
+++ top.c	11 Mar 2003 23:28:51 -0000
@@ -1144,7 +1144,7 @@
   if (annotation_suffix == NULL)
     annotation_suffix = "";
 
-  if (annotation_level > 1 && instream == stdin)
+  if (annotation_level == 2 && instream == stdin)
     {
       local_prompt = alloca ((prompt_arg == NULL ? 0 : strlen (prompt_arg))
 			     + strlen (annotation_suffix) + 40);
@@ -1197,7 +1197,7 @@
 	  error_pre_print = source_error;
 	}
 
-      if (annotation_level > 1 && instream == stdin)
+      if (annotation_level == 2 && instream == stdin)
 	{
 	  printf_unfiltered ("\n\032\032pre-");
 	  printf_unfiltered (annotation_suffix);
@@ -1218,7 +1218,7 @@
 	  rl = gdb_readline (local_prompt);
 	}
 
-      if (annotation_level > 1 && instream == stdin)
+      if (annotation_level == 2 && instream == stdin)
 	{
 	  printf_unfiltered ("\n\032\032post-");
 	  printf_unfiltered (annotation_suffix);
@@ -1932,8 +1932,8 @@
       PREFIX (0) = "";
       PROMPT (0) = savestring (DEFAULT_PROMPT, strlen (DEFAULT_PROMPT));
       SUFFIX (0) = "";
-      /* Set things up for annotation_level > 1, if the user ever decides
-         to use it. */
+      /* Set things up for annotation_level == 2, if the user ever
+         decides to use it. */
       async_annotation_suffix = "prompt";
       /* Set the variable associated with the setshow prompt command. */
       new_async_prompt = savestring (PROMPT (0), strlen (PROMPT (0)));
@@ -1941,7 +1941,7 @@
       /* If gdb was started with --annotate=2, this is equivalent to
 	 the user entering the command 'set annotate 2' at the gdb
 	 prompt, so we need to do extra processing. */
-      if (annotation_level > 1)
+      if (annotation_level == 2)
         set_async_annotation_level (NULL, 0, NULL);
     }
   gdb_prompt_escape = 0;	/* default to none.  */
Index: utils.c
===================================================================
RCS file: /cvs/src/src/gdb/utils.c,v
retrieving revision 1.98
diff -u -r1.98 utils.c
--- utils.c	26 Feb 2003 14:35:19 -0000	1.98
+++ utils.c	11 Mar 2003 23:28:52 -0000
@@ -1301,13 +1301,13 @@
       wrap_here ("");		/* Flush any buffered output */
       gdb_flush (gdb_stdout);
 
-      if (annotation_level > 1)
+      if (annotation_level == 2)
 	printf_filtered ("\n\032\032pre-query\n");
 
       vfprintf_filtered (gdb_stdout, ctlstr, args);
       printf_filtered ("(y or n) ");
 
-      if (annotation_level > 1)
+      if (annotation_level == 2)
 	printf_filtered ("\n\032\032query\n");
 
       wrap_here ("");
@@ -1344,7 +1344,7 @@
       printf_filtered ("Please answer y or n.\n");
     }
 
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_filtered ("\n\032\032post-query\n");
   return retval;
 }
@@ -1687,12 +1687,12 @@
   char *ignore;
   char cont_prompt[120];
 
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_unfiltered ("\n\032\032pre-prompt-for-continue\n");
 
   strcpy (cont_prompt,
 	  "---Type <return> to continue, or q <return> to quit---");
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     strcat (cont_prompt, "\n\032\032prompt-for-continue\n");
 
   /* We must do this *before* we call gdb_readline, else it will eventually
@@ -1713,7 +1713,7 @@
      out to DOS.  */
   ignore = gdb_readline_wrapper (cont_prompt);
 
-  if (annotation_level > 1)
+  if (annotation_level == 2)
     printf_unfiltered ("\n\032\032post-prompt-for-continue\n");
 
   if (ignore)

Re: [rfc] Annotation level THREE

[David Carlton]

On Tue, 11 Mar 2003 18:37:10 -0500, Andrew Cagney <ac131313@redhat.com> said:

> With this and its doco in, I think 5.4 is clear to go (or at least try to).

So what's the timetable for the branch and the release, exactly?  It
seems like we've suddenly switched to a much more hurried mode; should
the 5.4 branch be cut immediately, even before the annotation level
three change gets put in, so that we can avoid putting changes that
might inadvertently be destabilizing on the branch?  (Obviously the
annotation level 3 change would get added to the branch, as well as
bugfixes.)

David Carlton
carlton@math.stanford.edu

Re: [rfc] Annotation level THREE

[Andrew Cagney]

> On Tue, 11 Mar 2003 18:37:10 -0500, Andrew Cagney <ac131313@redhat.com> said:
> 
> 
>> With this and its doco in, I think 5.4 is clear to go (or at least try to).
> 
> 
> So what's the timetable for the branch and the release, exactly?  It
> seems like we've suddenly switched to a much more hurried mode; should
> the 5.4 branch be cut immediately, even before the annotation level
> three change gets put in, so that we can avoid putting changes that
> might inadvertently be destabilizing on the branch?  (Obviously the
> annotation level 3 change would get added to the branch, as well as
> bugfixes.)

See: http://sources.redhat.com/gdb/schedule/. `soon'.
We've been in a more hurried mode since January.

Should you delay your changes?  No.

Andrew

[rfc] Annotation level THREE

[Nick Roberts]

> To follow through a discussion on gdb@ this patch adds annotation level 
> three to the GDB sources.

> Annotation level three:

> - keeps the event notifications from annotation level two
> - removes all the output markups

I don't really follow this. It looks like level three annotations will have
a lot of the annotations missing. To currently work gdb-ui.el needs:

frames-invalid
breakpoints-invalid
pre-prompt
prompt
commands
overload-choice
query
prompt-for-continue
post-prompt
source
starting
exited
signalled
signal
breakpoint
watchpoint
frame-begin
stopped
display-begin
display-end
display-number-end
array-section-begin
array-section-end
field-begin
field-end

It needn't use frames-invalid and breakpoints-invalid which are repeatedly
generated during a run and possibly other selected ones could go. However,
some appear to be essential e.g display-begin as the MI equivalent,
-display-insert, isn't implemented and I don't know how to make use of
variable objects.

Nick

Re: [rfc] Annotation level THREE

[Andrew Cagney]

> I don't really follow this. It looks like level three annotations will have
> a lot of the annotations missing.

Yes.

The change should remove the annotations that were being used to mark up 
CLI output, but leave those that were notifying the GUI of various events.

The marked up output has been superseeded by ``interpreter mi ...''.

 > To currently work gdb-ui.el needs:
> 
> frames-invalid
> breakpoints-invalid
> pre-prompt
> prompt
> commands
> overload-choice
> query
> prompt-for-continue
> post-prompt
> source
> starting
> exited
> signalled
> signal
> breakpoint
> watchpoint
> frame-begin
> stopped
> display-begin
> display-end
> display-number-end
> array-section-begin
> array-section-end
> field-begin
> field-end
> 
> It needn't use frames-invalid and breakpoints-invalid which are repeatedly
> generated during a run and possibly other selected ones could go. However,
> some appear to be essential e.g display-begin as the MI equivalent,
> -display-insert, isn't implemented and I don't know how to make use of
> variable objects.

Why do you need display-{begin,end}?  -display-insert has been made 
redundant by the varobj stuff - it lets the GUI efficiently track its 
display values outside of the CLI.   The testsuite is a good source of 
varobj examples (unfortunatly lacking from the doco):
http://sources.redhat.com/gdb/current/onlinedocs/gdb_25.html#SEC565

The above list also contains thing like field-{begin,end}, 
array-section-{begin,end} et.al.  Why are they needed.

Andrew

Re: [rfc] Annotation level THREE

[Nick Roberts]

 > > I don't really follow this. It looks like level three annotations will have
 > > a lot of the annotations missing.
 > 
 > Yes.
 > 
 > The change should remove the annotations that were being used to mark up 
 > CLI output, but leave those that were notifying the GUI of various events.
 > 
 > The marked up output has been superseeded by ``interpreter mi ...''.
 > 
 >  > To currently work gdb-ui.el needs:
 > > 
 > > frames-invalid
 > > breakpoints-invalid
 > > pre-prompt
 > > prompt
 > > commands
 > > overload-choice
 > > query
 > > prompt-for-continue
 > > post-prompt
 > > source
 > > starting
 > > exited
 > > signalled
 > > signal
 > > breakpoint
 > > watchpoint
 > > frame-begin
 > > stopped
 > > display-begin
 > > display-end
 > > display-number-end
 > > array-section-begin
 > > array-section-end
 > > field-begin
 > > field-end
 > > 
 > > It needn't use frames-invalid and breakpoints-invalid which are repeatedly
 > > generated during a run and possibly other selected ones could go. However,
 > > some appear to be essential e.g display-begin as the MI equivalent,
 > > -display-insert, isn't implemented and I don't know how to make use of
 > > variable objects.
 > 
 > Why do you need display-{begin,end}?  -display-insert has been made 
 > redundant by the varobj stuff - it lets the GUI efficiently track its 
 > display values outside of the CLI.  

Variable objects don't auto-display. You seem to have to type
-var-evaluate-expression each time the program stops. 

 >  The testsuite is a good source of 
 > varobj examples (unfortunatly lacking from the doco):
 > http://sources.redhat.com/gdb/current/onlinedocs/gdb_25.html#SEC565

The lack of documentation for (and apparent completeness of) GDB/MI is part of
the problem. I realise that I have no service agreement and cannot expect
anything but I would prefer more effort to be directed towards MI before (a
large number of) annotations are removed.

 > The above list also contains thing like field-{begin,end}, 
 > array-section-{begin,end} et.al.  Why are they needed.

I use them to parse the output. They could probably go, if necessary, but
others that you plan to take out *are* needed.

Nick

Re: [rfc] Annotation level THREE

[Andrew Cagney]

>  > 
>  > Why do you need display-{begin,end}?  -display-insert has been made 
>  > redundant by the varobj stuff - it lets the GUI efficiently track its 
>  > display values outside of the CLI.  
> 
> Variable objects don't auto-display. You seem to have to type
> -var-evaluate-expression each time the program stops. 

Why do you need auto-display?  What are you using it for?

Remember, every time the target changes (e.g., from a user modifying a 
variable or register), the display needs to be updated.  This is because 
that variable/register has the potential to modify every single value 
being displayed.  Further, unless your using some sort of changes-only 
mechanism, such as provided by the varobj, the display windows are just 
not going to scale.

>  >  The testsuite is a good source of 
>  > varobj examples (unfortunatly lacking from the doco):
>  > http://sources.redhat.com/gdb/current/onlinedocs/gdb_25.html#SEC565
> 
> The lack of documentation for (and apparent completeness of) GDB/MI is part of
> the problem.

Um, the varobj is documented.  It just lacks a vew concrete examples. 
Those can be found by examining the testsuite.  Both Apple and Eclipse 
are using this part of the MI.

>  > The above list also contains thing like field-{begin,end}, 
>  > array-section-{begin,end} et.al.  Why are they needed.
> 
> I use them to parse the output. They could probably go, if necessary, but
> others that you plan to take out *are* needed.

Can you please be more specific?

Andrew

Re: [rfc] Annotation level THREE

[Nick Roberts]

 > >  > Why do you need display-{begin,end}?  -display-insert has been made 
 > >  > redundant by the varobj stuff - it lets the GUI efficiently track its 
 > >  > display values outside of the CLI.  
 > > 
 > > Variable objects don't auto-display. You seem to have to type
 > > -var-evaluate-expression each time the program stops. 
 > 
 > Why do you need auto-display?  What are you using it for?
 > 
 > Remember, every time the target changes (e.g., from a user modifying a 
 > variable or register), the display needs to be updated.  This is because 
 > that variable/register has the potential to modify every single value 
 > being displayed.  Further, unless your using some sort of changes-only 
 > mechanism, such as provided by the varobj, the display windows are just 
 > not going to scale.

You're right. If the user assigns a value to a variable, using my code, the
display window for that variable won't update in Emacs until the next
statement is executed.

What do you mean by `not going to scale'? Currently if I display an array
slice, say just a few elements from a large array, I need to parse them from
output for the whole array. Could I arrange for GDB to just output the elements
I want using variable objects?

Can I get GDB to tell me what the current list of variable objects is? Can
I generate names for them automatically?

 > >  >  The testsuite is a good source of 
 > >  > varobj examples (unfortunatly lacking from the doco):
 > >  > http://sources.redhat.com/gdb/current/onlinedocs/gdb_25.html#SEC565
 > > 
 > > The lack of documentation for (and apparent completeness of) GDB/MI is part of
 > > the problem.
 > 
 > Um, the varobj is documented.  It just lacks a vew concrete examples. 
 > Those can be found by examining the testsuite.  Both Apple and Eclipse 
 > are using this part of the MI.

Its a question of resources. I'm one person doing things in my spare time.
Apple and Eclipse have full time teams dedicated to the task.

 > >  > The above list also contains thing like field-{begin,end}, 
 > >  > array-section-{begin,end} et.al.  Why are they needed.
 > > 
 > > I use them to parse the output. They could probably go, if necessary, but
 > > others that you plan to take out *are* needed.
 > 
 > Can you please be more specific?

Perhaps I could turn that question round. Which annotations are you planning
to keep?

Nick

Re: [rfc] Annotation level THREE

[Andrew Cagney]

>  > >  > Why do you need display-{begin,end}?  -display-insert has been made 
>  > >  > redundant by the varobj stuff - it lets the GUI efficiently track its 
>  > >  > display values outside of the CLI.  
>  > > 
>  > > Variable objects don't auto-display. You seem to have to type
>  > > -var-evaluate-expression each time the program stops. 
>  > 
>  > Why do you need auto-display?  What are you using it for?
>  > 
>  > Remember, every time the target changes (e.g., from a user modifying a 
>  > variable or register), the display needs to be updated.  This is because 
>  > that variable/register has the potential to modify every single value 
>  > being displayed.  Further, unless your using some sort of changes-only 
>  > mechanism, such as provided by the varobj, the display windows are just 
>  > not going to scale.
> 
> You're right. If the user assigns a value to a variable, using my code, the
> display window for that variable won't update in Emacs until the next
> statement is executed.

Even simple things, like trying to compute ``1 + 2'' (rather than 
``1+2'') won't work without MI.

> What do you mean by `not going to scale'?

There are a numer of factors that determine IDE performance (as defined 
by single-step):

- ide screen update (gui overhead)
- ide <-> gdb overhead
- gdb <-> inferior
- system load/overhead

If the IDE refreshes all display elements (instead of those that have 
changed) then single-step performance will be dominated by the number of 
visual elements that need to be refreshed.  Any ide<->gdb overhead will 
be in the noise.

 > Currently if I display an array
> slice, say just a few elements from a large array, I need to parse them from
> output for the whole array. Could I arrange for GDB to just output the elements
> I want using variable objects?

I don't know.  Perhaphs ask this on gdb@ as a specific question.

> Can I get GDB to tell me what the current list of variable objects is?

The assumption is that the IDE is tracking the mapping between each of 
its local display elements and the corresponding varobj.

 > Can
> I generate names for them automatically?

I'm not sure what you mean.  Looking at the doco

-var-create - * i

automatically assigns the varobj name.

Andrew



>  > >  >  The testsuite is a good source of 
>  > >  > varobj examples (unfortunatly lacking from the doco):
>  > >  > http://sources.redhat.com/gdb/current/onlinedocs/gdb_25.html#SEC565
>  > > 
>  > > The lack of documentation for (and apparent completeness of) GDB/MI is part of
>  > > the problem.
>  > 
>  > Um, the varobj is documented.  It just lacks a vew concrete examples. 
>  > Those can be found by examining the testsuite.  Both Apple and Eclipse 
>  > are using this part of the MI.
> 
> Its a question of resources. I'm one person doing things in my spare time.
> Apple and Eclipse have full time teams dedicated to the task.
> 
>  > >  > The above list also contains thing like field-{begin,end}, 
>  > >  > array-section-{begin,end} et.al.  Why are they needed.
>  > > 
>  > > I use them to parse the output. They could probably go, if necessary, but
>  > > others that you plan to take out *are* needed.
>  > 
>  > Can you please be more specific?
> 
> Perhaps I could turn that question round. Which annotations are you planning
> to keep?
> 
> Nick
> 

Re: [rfc] Annotation level THREE

[Andrew Cagney]

>> >  > The above list also contains thing like field-{begin,end}, 
>  > >  > array-section-{begin,end} et.al.  Why are they needed.
>  > > 
>  > > I use them to parse the output. They could probably go, if necessary, but
>  > > others that you plan to take out *are* needed.
>  > 
>  > Can you please be more specific?
> 
> Perhaps I could turn that question round. Which annotations are you planning
> to keep?

I think annotations can be split into two categores:

- events
These let GDB notify the GUI of internal state changes.

- markups
These try to make CLI output, intended solely for a human, machine parsable.

The events remain (target changed, breakpoint created, ....).  The 
markups are removed (*-{begin,end})

Andrew

Re: [rfc] Annotation level THREE

[Bob Rossi]

On Tue, Mar 18, 2003 at 11:00:18AM -0500, Andrew Cagney wrote:
> >>>  > The above list also contains thing like field-{begin,end}, 
> > > >  > array-section-{begin,end} et.al.  Why are they needed.
> > > > 
> > > > I use them to parse the output. They could probably go, if 
> > necessary, but
> > > > others that you plan to take out *are* needed.
> > > 
> > > Can you please be more specific?
> >
> >Perhaps I could turn that question round. Which annotations are you 
> >planning
> >to keep?
> 
> I think annotations can be split into two categores:
> 
> - events
> These let GDB notify the GUI of internal state changes.
> 
> - markups
> These try to make CLI output, intended solely for a human, machine 
> parsable.
> 
> The events remain (target changed, breakpoint created, ....).  The 
> markups are removed (*-{begin,end})
> 
> Andrew
> 

Here is my humble opinion.

I do see a problem with annotate level 3. I don't understand why GDB
should introduce another level of complexity to the annotation problem.
( The problem being the switch from annotation to mi ).

It doesn't really make sense to me that several releases of GDB will
support an annotation level of 3.I think it would be great if 
annotations were deprecated after MI was fully ready to take its place.
If MI is "ready" to replace annotations, then it should. I don't see how
removing several annotations really saves the GDB developers anything.

I think the proof that MI is ready is to see at least one console
implementation of a front end to GDB. I don't expect to see proof. I do
however wonder what kind of a mess we will be in if front ends can not
make a console implementation complete with a certain version of GDB
because of some lack of support in MI. To stack problems on top of that,
the front end will be using a combination of annotation/MI commands
which to me seems to complicated. After all, this is a simple problem,
and we are smart people :).

1. In the future all front ends will have to put up with supporting the
possibility of having annotation level 3. This seems like it would be a
more complex way to determine problems with the front end.

2. Front ends will at some point
   a. use only annotations to communicate with GDB.
   b. use a hybrid of annotations / MI to communicate with GDB.
   c. use only MI to communicate with GDB.
   
   This seems to be an overly complex way to transition between the
   two. It seems as if annotations should stay until MI is ready to be
   used to replace all of the annotations.
   Why would we want to place part (b) on front ends. That penalty has
   an order of magnitude of N for front ends that will use annotate level
   2 to communicate with GDB. This is a clear violation of the DRY 
   principle.

3. Someone like me will start to write a front end and say
   "Hey, annotation level 3 is cool, I will use it to write a front end
   to GDB". Then we will have another problem. :)

Bob Rossi

Re: [rfc] Annotation level THREE

[Michael Elizabeth Chastain]

Hi Andrew,

> With this and its doco in, I think 5.4 is clear to go (or at least try to).

The last time I looked in detail was 2003-02-16:

  http://sources.redhat.com/ml/gdb/2003-02/msg00257.html

At that time, there were still several high priority PR's about build
issues; x86-64 regresions; and java fails the 'break main' test.

Do you care about any of these things?

Michael C

Re: [rfc] Annotation level THREE

[Andrew Cagney]

> Hi Andrew,
> 
> 
>> With this and its doco in, I think 5.4 is clear to go (or at least try to).
> 
> 
> The last time I looked in detail was 2003-02-16:
> 
>   http://sources.redhat.com/ml/gdb/2003-02/msg00257.html
> 
> At that time, there were still several high priority PR's about build
> issues; x86-64 regresions; and java fails the 'break main' test.
> 
> Do you care about any of these things?

`or at least try to'.  As far as I know this is the only feature that 
could block the next release.  It's critical that a GDB release 
containing this be made soon.

- x86-64 was always broken
- java improvements would be nice

A real concern is that `long long' regression.

Andrew

Re: [rfc] Annotation level THREE

[Daniel Jacobowitz]

On Wed, Mar 12, 2003 at 09:50:02AM -0500, Andrew Cagney wrote:
> >Hi Andrew,
> >
> >
> >>With this and its doco in, I think 5.4 is clear to go (or at least try 
> >>to).
> >
> >
> >The last time I looked in detail was 2003-02-16:
> >
> >  http://sources.redhat.com/ml/gdb/2003-02/msg00257.html
> >
> >At that time, there were still several high priority PR's about build
> >issues; x86-64 regresions; and java fails the 'break main' test.
> >
> >Do you care about any of these things?
> 
> `or at least try to'.  As far as I know this is the only feature that 
> could block the next release.  It's critical that a GDB release 
> containing this be made soon.
> 
> - x86-64 was always broken

Eh, I believe that x86-64 worked in GDB 5.3, judging from Michal's
comments.

> - java improvements would be nice
> 
> A real concern is that `long long' regression.

It's down the road behind my currently pending DWARF-2 patch.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfc] Annotation level THREE

[David Carlton]

On Wed, 12 Mar 2003 09:50:02 -0500, Andrew Cagney <ac131313@redhat.com> said:

> - java improvements would be nice

I'll try to give some of the failing Java tests a look this week or
next, now that I have gcj 3.2 installed on my home machine.  I won't
promise anything, but with luck it will be some sort of interaction
between (de)mangled names and linespec and so forth that I'll be able
to sniff out.

David Carlton
carlton@math.stanford.edu