Re: MI testsuite improvements

[Bob Rossi <bob at brasko dot net>]

On Fri, Feb 11, 2005 at 09:19:13PM -0500, Bob Rossi wrote:
> On Fri, Feb 11, 2005 at 02:34:52PM -0500, Andrew Cagney wrote:
> > Bob Rossi wrote:
> > >On Thu, Feb 10, 2005 at 03:52:08PM -0500, Andrew Cagney wrote:
> > >
> > >>>OO, I see, are you saying the mi-* tests will become the new ones, and
> > >>>the mi2-* are frozen for the mi2-* development cycle?
> > >>>
> > >>>In order to do this for only the new tests, I'll have to add a new
> > >>>parameter to mi_gdb_start to tell it to either open or not open a pty 
> > >>>for the inferior. Hope this will be OK.
> > >>
> > >>M'kay.
> > 
> > I've thought hard about this one.  I'm ok with the theory in that we 
> > should have a test of GDB against a "pipe" (i.e., something that doesn't 
> > echo).  I've reservations about applying it across all tests though.
> > 
> > At present you can look at the log and see the exact interaction as 
> > you'll get when you run that same GDB in a normal terminal.  This change 
> > alters that.
> > 
> > Can you post an example log so that we can see what it looks like.
> 
> Andrew, sorry if you recieved the last Email from me directly.
> Sourceware bounced the Email from the GDB list, because it was to large.
> For your info, I attached mi-console.exp and mi-syn-frame.exp log
> information, because those 2 have the most inferior I/O.
> 
> I've attached new_gdb.log and original_gdb.log. I actually modified 
> new_gdb.log so that the PATH is the same in both. Let me know if this 
> isn't OK. It does make looking at the diff much simpler.
> 
> It's obviously your call on if it's OK to use the new PTY on all the
> tests. I kind of prefer it, since at this point, there is no way to
> write a reliable front end to GDB without using the PTY. For example,
> there's no way to reliably parse the output of GDB when the inferior is
> mixing it's output in the same stream. Especially if you are debugging
> your own front end to GDB!
> 
> Also, there's several other advanatage which I mentioned, including,
>    - anchoring all the output of the GDB
>    - anchoring all the output of the Inferior
>    - parsing the output of GDB to get a syntax check
>    - later advantages of parsing the output of GDB to use semantically
> 
> Let me know what you think. If you want the dbg.log files, I can provide
> them.

Any headway on this? Need some more info?

Thanks,
Bob Rossi