Re: Patch for gdb/mi 604

["J. Johnston" <jjohnstn@redhat.com>]

Elena Zannoni wrote:
> 
> 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

Patch committed with comments added in lib/mi-support.exp.

-- Jeff J.