This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MI testsuite improvements


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.

Thanks,
Bob Rossi

Attachment: new_gdb.log
Description: Text document

Attachment: original_gdb.log
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]