Re: Patch for gdb/mi 604

[Elena Zannoni <ezannoni@redhat.com>]

J. Johnston writes:
 > >  >      PR gdb/604.Index: mi-main.c
 > >  > ===================================================================
 > >  > RCS file: /cvs/src/src/gdb/mi/mi-main.c,v
 > >  > retrieving revision 1.35
 > >  > diff -u -r1.35 mi-main.c
 > >  > --- mi-main.c        23 Oct 2002 21:17:51 -0000      1.35
 > >  > +++ mi-main.c        7 Nov 2002 01:04:06 -0000
 > >  > @@ -1464,12 +1464,16 @@
 > >  >  static void
 > >  >  mi_command_loop (int mi_version)
 > >  >  {
 > >  > -  /* HACK: Force stdout/stderr to point at the console.  This avoids
 > >  > -     any potential side effects caused by legacy code that is still
 > >  > -     using the TUI / fputs_unfiltered_hook */
 > >  > -  raw_stdout = stdio_fileopen (stdout);
 > >  > -  /* Route normal output through the MIx */
 > >  > -  gdb_stdout = mi_console_file_new (raw_stdout, "~");
 > >  > +  if (mi_version <= 1)
 > >  > +    {
 > >  > +      /* HACK: Force stdout/stderr to point at the console.  This avoids
 > >  > +         any potential side effects caused by legacy code that is still
 > >  > +         using the TUI / fputs_unfiltered_hook */
 > >  > +      raw_stdout = stdio_fileopen (stdout);
 > >  > +      /* Route normal output through the MIx */
 > >  > +      gdb_stdout = mi_console_file_new (raw_stdout, "~");
 > >  > +    }
 > >  > +
 > >  >    /* Route error and log output through the MI */
 > >  >    gdb_stderr = mi_console_file_new (raw_stdout, "&");
 > >  >    gdb_stdlog = gdb_stderr;
 > > 
 > > I don't understand why the code that handles this is in 2 different
 > > places depending on the interpreter version. I must be missing
 > > something, mi_init_ui is called with -i=mi2 and with -i=mi1.
 > > 
 > 
 > It's a timing issue.  The old code used to set gdb_stdout up in mi_command_loop.  By that
 > time, the initial message has already been issued and not "consolized".
 > Because I was attempting not to disturb the mi1 interface, I have to put
 > the code in the right spot for mi2 and above, and leave it in the wrong spot
 > for mi1 and below.  Both places have to make the check for the mi level.
 > 

Oh right, yes, you are *not* changing this for mi1.

 > >  > Index: lib/mi-support.exp
 > >  > ===================================================================
 > >  > RCS file: /cvs/src/src/gdb/testsuite/lib/mi-support.exp,v
 > >  > retrieving revision 1.17
 > >  > diff -u -r1.17 mi-support.exp
 > >  > --- lib/mi-support.exp       10 Sep 2002 22:28:19 -0000      1.17
 > >  > +++ lib/mi-support.exp       7 Nov 2002 01:14:58 -0000
 > >  > @@ -123,7 +123,20 @@
 > >  >      return 1;
 > >  >      }
 > >  >      gdb_expect {
 > >  > -    -re ".*$mi_gdb_prompt$" {
 > >  > +    -re "~\"GNU.*\r\n~\".*$mi_gdb_prompt$" {
 > >  > +        if { $MIFLAGS == "-i=mi1" } {
 > >  > +            perror "(mi startup) Got unexpected new mi prompt."
 > > 
 > > I am wondering if it should use 'untested' instead of 'perror'. That's
 > > what the other cases do.
 > >
 > 
 > I had this originally, but I figured that the tests should flag an error
 > if the wrong type of message is issued for either mi setting.  Simply
 > placing them in the untested bucket would probably get them ignored.

Yes, I see, untested doesn't print anything special. Can you add a
comment to the testfile about this?

Approved otherwise.

thanks
Elena