Re: Patch for gdb/mi 604

J. Johnston
2002-11-08T20:39:54Z

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.