From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6160 invoked by alias); 8 Nov 2002 20:39:54 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 6150 invoked from network); 8 Nov 2002 20:39:51 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 8 Nov 2002 20:39:51 -0000 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 04DE4800019; Fri, 8 Nov 2002 15:39:51 -0500 (EST) Message-ID: <3DCC2116.D191D6A5@redhat.com> Date: Fri, 08 Nov 2002 12:39:00 -0000 From: "J. Johnston" Organization: Red Hat Inc. X-Accept-Language: en MIME-Version: 1.0 To: Elena Zannoni Cc: Andrew Cagney , gdb-patches@sources.redhat.com Subject: Re: Patch for gdb/mi 604 References: <3D9B3D4D.C0B57920@redhat.com> <15796.32490.200752.700605@localhost.redhat.com> <3DB487CB.7F21B13@redhat.com> <15797.24525.445748.958598@localhost.redhat.com> <3DB56C6F.7000108@redhat.com> <3DC9C05D.3A1B0809@redhat.com> <15818.63155.762935.993550@localhost.redhat.com> <3DCAFA89.C1C67B91@redhat.com> <15819.49989.112310.320542@localhost.redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-11/txt/msg00246.txt.bz2 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.