Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "J. Johnston" <jjohnstn@redhat.com>
To: Elena Zannoni <ezannoni@redhat.com>
Cc: Andrew Cagney <ac131313@redhat.com>, gdb-patches@sources.redhat.com
Subject: Re: Patch for gdb/mi 604
Date: Thu, 07 Nov 2002 15:43:00 -0000	[thread overview]
Message-ID: <3DCAFA89.C1C67B91@redhat.com> (raw)
In-Reply-To: <15818.63155.762935.993550@localhost.redhat.com>

Elena Zannoni wrote:
> 
> J. Johnston writes:
>  > Andrew Cagney wrote:
>  > >
>  > > > J. Johnston writes:
>  > > >  > Elena Zannoni wrote:
>  > > >  > >
>  > > >  > > J. Johnston writes:
>  > > >  > >  > The following patches mi-main.c to turn on the console output prefix prior
>  > > >  > >  > to outputting the gdb startup messages.  The code checks for mi level
>  > > >  > >  > and defers to old behavior for mi1.
>  > > >  > >  >
>  > > >  > >  > Ok to commit?
>  > > >  > >  >
>  > > >  > >
>  > > >  > > Wouldn't this affect the testsuite as well?
>  > > >  > > Or is this behavior not tested?
>  > > >  > >
>  > > >  > > Elena
>  > > >  > >
>  > > >  >
>  > > >  > It does not affect the testsuite.  The testsuite startup code looks for
>  > > >  > the gdb prompt or some form of error indication, but does not specifically
>  > > >  > look at the start-up message.
>  > > >  >
>  > > >
>  > > > Hmm, I wonder whether now it should. Since we are expecting a specific
>  > > > behavior it might as well be tested. Thoughts?
>  > >
>  > > It _needs_ to be tested - if it isn't tested it doesn't work :-)
>  > >
>  > > Andrew
>  >
>  > On that note, I have provided here a patch to the mi-support.exp file in
>  > gdb/testsuite/lib.  It checks the startup message for mi and mi1 in
>  > the mi startup routine.
>  >
>  > I have also reincluded the code patch.  Please let me know if this is ok to
>  > check in.
>  >
>  > -- Jeff J.
>  >
>  > gdb/testsuite/ChangeLog:
>  >
>  > 2002-11-06  Jeff Johnston  <jjohnstn@redhat.com>
>  >
>  >      * lib/mi-support.exp (mi_gdb_start): Verify the startup message for mi1 and
>  >      current mi is in correct format.  New mi startup message should be in
>  >      console format.  This is part of fix for PR gdb/604.
>  >
>  > gdb/mi/ChangeLog:
>  >
>  > 2002-11-06  Jeff Johnston  <jjohnstn@redhat.com>
>  >
>  >      * mi-main.c (mi_command_loop): Initialize raw_stdout and gdb_stdout only if
>  >      mi version is <= 1.
>  >      (mi_init_ui): Initialize raw_stdout and gdb_stdout if mi version is > 1 so
>  >      startup message is treated as console output.  This is part of fix for
>  >      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.


> Elena
> 
>  > @@ -1541,8 +1545,16 @@
>  >  static void
>  >  mi_init_ui (char *arg0)
>  >  {
>  > -  /* Eventually this will contain code that takes control of the
>  > -     console. */
>  > +  if (strlen (interpreter_p) <= 2 ||
>  > +      interpreter_p[2] > '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, "~");
>  > +    }
>  >  }
>  >
>  >  void
>  > 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.
 
>  > +            remote_close host;
>  > +            return -1;
>  > +        }
>  > +        verbose "GDB initialized."
>  > +    }
>  > +    -re "\[^~\].*$mi_gdb_prompt$" {
>  > +        if { $MIFLAGS != "-i=mi1" } {
>  > +            perror "(mi startup) Got unexpected old mi prompt."
>  > +            remote_close host;
>  > +            return -1;
>  > +        }
>  >          verbose "GDB initialized."
>  >      }
>  >      -re ".*$gdb_prompt $" {


  reply	other threads:[~2002-11-07 23:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-02 11:39 J. Johnston
2002-10-21 15:28 ` Elena Zannoni
2002-10-21 16:03   ` J. Johnston
2002-10-22  7:28     ` Elena Zannoni
2002-10-22  8:19       ` Andrew Cagney
2002-11-06 17:22         ` J. Johnston
2002-11-07 15:30           ` Elena Zannoni
2002-11-07 15:43             ` J. Johnston [this message]
2002-11-08  6:03               ` Elena Zannoni
2002-11-08 12:39                 ` J. Johnston

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3DCAFA89.C1C67B91@redhat.com \
    --to=jjohnstn@redhat.com \
    --cc=ac131313@redhat.com \
    --cc=ezannoni@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox