Re: [commit/obish] Fix cntrl-z

Re: [commit/obish] Fix cntrl-z

[Michael Elizabeth Chastain]

I ran annota2.exp 1000 times with gcc v2 and v3, dwarf-2 and stabs+.

    $ cat r-*/*/*/gdb.sum | grep annotate-quit | sort | uniq -c
    977 KFAIL: gdb.c++/annota2.exp: annotate-quit (PRMS: gdb/544)
     23 PASS: gdb.c++/annota2.exp: annotate-quit

This is with 'cvs -D 2003-02-12 20:00:55 UTC'.

I'm also on a busy system (building gcc's all day long).
I can run it again on an idle system in a few hours.

This test was all PASSes on 300 runs on '2003-02-09 18:18:02 UTC'.
cvs -D ... -D ... indicates that the command loop changes are the only
significant change.

The ^Z part does work though.

Michael C

Re: [commit/obish] Fix cntrl-z

[Michael Elizabeth Chastain]

Okay, I re-ran this test on an idle system and it's even worse.

    $ cat r-*/*/*/gdb.sum | grep annotate-quit | sort | uniq -c
    997 KFAIL: gdb.c++/annota2.exp: annotate-quit (PRMS: gdb/544)
      3 PASS: gdb.c++/annota2.exp: annotate-quit

Again, this is with 'cvs -D 2003-02-12 20:00:55 UTC'.

Michael C

Re: [commit/obish] Fix cntrl-z

[Michael Elizabeth Chastain]

Yeah, I saw the same improvement in annotate-quit that David C did.
I recorded the dates in a message to gdb-gnats, and the only
plausible code difference was in the interpreter.

I'm checking out a fresh gdb right now and I will run a few hundred
annota2.exp runs on it.  I'll have some news in about an hour.

Michael C

[commit/obish] Fix cntrl-z

[Andrew Cagney]

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

Hello,

The attatched gets rid of the immediate problem of cntrl-z not working. 
   When async, it calls cli_command_loop.  Thanks to mark for analyzing 
the problem.

It should eventually be called via the CLI interpreter's command loop 
but that can follow.  This is to get over the immediate problem (and 
hey, while we're at it, eliminate a reference to the global 
command_loop_hook).

committed,
Andrew

PS: The TUI also appears to have also suffered in the fallout :-(

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

2003-02-12  Andrew Cagney  <ac131313@redhat.com>

	* event-top.c (cli_command_loop): Delete declaration.
	(_initialize_event_loop): Delete function setting event_loop_hook.
	* event-top.h (cli_command_loop): Declare.  Update copyright.
	(EVENT_TOP_H): Define.  Wrap header in #ifdef EVENT_TOP_H.
	* interps.c (current_interp_command_loop): When event_loop_p, call
	cli_command_loop.

Index: event-top.c
===================================================================
RCS file: /cvs/src/src/gdb/event-top.c,v
retrieving revision 1.25
diff -u -r1.25 event-top.c
--- event-top.c	6 Feb 2003 01:19:12 -0000	1.25
+++ event-top.c	12 Feb 2003 15:26:19 -0000
@@ -39,15 +39,12 @@
 /* readline defines this.  */
 #undef savestring
 
-extern void _initialize_event_loop (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);
 static void change_line_handler (void);
 static void change_annotation_level (void);
 static void command_handler (char *command);
-void cli_command_loop (void);
 static void async_do_nothing (gdb_client_data arg);
 static void async_disconnect (gdb_client_data arg);
 static void async_stop_sig (gdb_client_data arg);
@@ -1199,12 +1196,3 @@
       delete_file_handler (input_fd);
     }
 }
-
-void
-_initialize_event_loop (void)
-{
-  /* Tell gdb to use the cli_command_loop as the main loop. */
-  if (event_loop_p && command_loop_hook == NULL)
-    command_loop_hook = cli_command_loop;
-}
-
Index: event-top.h
===================================================================
RCS file: /cvs/src/src/gdb/event-top.h,v
retrieving revision 1.5
diff -u -r1.5 event-top.h
--- event-top.h	6 Feb 2003 01:19:12 -0000	1.5
+++ event-top.h	12 Feb 2003 15:26:19 -0000
@@ -1,5 +1,7 @@
-/* Definitions used by GDB event-top.c.
-   Copyright 1999, 2001 Free Software Foundation, Inc.
+/* Definitions used by event-top.c, for GDB, the GNU debugger.
+
+   Copyright 1999, 2001, 2003 Free Software Foundation, Inc.
+
    Written by Elena Zannoni <ezannoni@cygnus.com> of Cygnus Solutions.
 
    This file is part of GDB.
@@ -19,6 +21,9 @@
    Foundation, Inc., 59 Temple Place - Suite 330,
    Boston, MA 02111-1307, USA.  */
 
+#ifndef EVENT_TOP_H
+#define EVENT_TOP_H
+
 /* Stack for prompts.  Each prompt is composed as a prefix, a prompt
    and a suffix.  The prompt to be displayed at any given time is the
    one on top of the stack.  A stack is necessary because of cases in
@@ -111,3 +116,7 @@
 extern void (*input_handler) (char *);
 extern int input_fd;
 extern void (*after_char_processing_hook) (void);
+
+extern void cli_command_loop (void);
+
+#endif
Index: interps.c
===================================================================
RCS file: /cvs/src/src/gdb/interps.c,v
retrieving revision 1.3
diff -u -r1.3 interps.c
--- interps.c	9 Feb 2003 10:47:37 -0000	1.3
+++ interps.c	12 Feb 2003 15:26:19 -0000
@@ -275,6 +275,8 @@
   else if (current_interpreter != NULL
 	   && current_interpreter->procs->command_loop_proc != NULL)
     current_interpreter->procs->command_loop_proc (current_interpreter->data);
+  else if (event_loop_p)
+    cli_command_loop ();
   else
     command_loop ();
 }

Re: [commit/obish] Fix cntrl-z

[David Carlton]

On Wed, 12 Feb 2003 16:36:28 +0100, Andrew Cagney <ac131313@redhat.com> said:

> The attatched gets rid of the immediate problem of cntrl-z not
> working.  When async, it calls cli_command_loop.  Thanks to mark for
> analyzing the problem.

This patch (or some other patch since yesterday and today) causes
gdb.c++/annota2.exp: annotate-quit (PR gdb/544) to start KFAILing
again for me.  (It had been passing since the interpreter stuff
finished merging in a week or two ago.)

An old, harmless bug is probably better than a new, more annoying bug,
but do you think there's any way to fix the cntrl-z issue while still
fixing gdb/544?

David Carlton
carlton@math.stanford.edu

Re: [commit/obish] Fix cntrl-z

[Daniel Jacobowitz]

On Wed, Feb 12, 2003 at 09:35:17AM -0800, David Carlton wrote:
> On Wed, 12 Feb 2003 16:36:28 +0100, Andrew Cagney <ac131313@redhat.com> said:
> 
> > The attatched gets rid of the immediate problem of cntrl-z not
> > working.  When async, it calls cli_command_loop.  Thanks to mark for
> > analyzing the problem.
> 
> This patch (or some other patch since yesterday and today) causes
> gdb.c++/annota2.exp: annotate-quit (PR gdb/544) to start KFAILing
> again for me.  (It had been passing since the interpreter stuff
> finished merging in a week or two ago.)
> 
> An old, harmless bug is probably better than a new, more annoying bug,
> but do you think there's any way to fix the cntrl-z issue while still
> fixing gdb/544?

Woah!  Deterministic behavior on the annotate-quit test?  It's probably
something in the CLI command loop then...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [commit/obish] Fix cntrl-z

[David Carlton]

On Wed, 12 Feb 2003 13:42:32 -0500, Daniel Jacobowitz <drow@mvista.com> said:

> Woah!  Deterministic behavior on the annotate-quit test?

Yeah.  It had actually always been deterministic for me: I never saw
it pass.  Then it started always passing after the interpreter merge.
But when I saw the aforementioned patch go by, I thought that might
undo the good work, and sure enough, it did.  Michael Chastain has
also made similar observations (though he hasn't yet had time to
verify my observation from today).  So:

> It's probably something in the CLI command loop then...

We do seem to have enough data to make this sound plausible.  Though
I'm not familiar enough with the code in question to say anything
more.

David Carlton
carlton@math.stanford.edu

Re: [commit/obish] Fix cntrl-z

[Andrew Cagney]

> On Wed, 12 Feb 2003 13:42:32 -0500, Daniel Jacobowitz <drow@mvista.com> said:
> 
> 
>> Woah!  Deterministic behavior on the annotate-quit test?
> 
> 
> Yeah.  It had actually always been deterministic for me: I never saw
> it pass.  Then it started always passing after the interpreter merge.
> But when I saw the aforementioned patch go by, I thought that might
> undo the good work, and sure enough, it did.  Michael Chastain has
> also made similar observations (though he hasn't yet had time to
> verify my observation from today).  So:

Given the interps change wasn't ment to affect that annotate test, I 
don't think that it suddenly working can really be thought of as `good 
work'.  It just happens to make it work, probably because something 
is/isn't being flushed now.

>> It's probably something in the CLI command loop then...
> 
> 
> We do seem to have enough data to make this sound plausible.  Though
> I'm not familiar enough with the code in question to say anything
> more.

Andrew