Re: Patch for gdb/mi 604

Elena Zannoni
2002-11-08T14:03:52Z

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