From: Bob Rossi <bob@brasko.net>
To: gdb-patches@sources.redhat.com, Nick Roberts <nickrob@snap.net.nz>
Subject: Re: MI testsuite to use PTY for inferior
Date: Sun, 31 Jul 2005 21:20:00 -0000 [thread overview]
Message-ID: <20050731212021.GA24144@white> (raw)
In-Reply-To: <20050731153051.GA28158@nevyn.them.org>
On Sun, Jul 31, 2005 at 11:30:52AM -0400, Daniel Jacobowitz wrote:
> On Sun, Jul 31, 2005 at 09:16:53AM -0400, Bob Rossi wrote:
> > On Sat, Jul 30, 2005 at 09:21:11PM -0400, Daniel Jacobowitz wrote:
> > > On Sat, Jul 30, 2005 at 07:03:09PM -0400, Bob Rossi wrote:
> > > > However, since that's pretty ugly, I'll take your suggestion and always
> > > > create and assign inferior_pty a value. Then I'll check it for the value
> > > > of "true" before executing any code.
> > >
> > > I recommend doing something different. Make the argument a flag, i.e.
> > > "mi_gdb_start use-tty". Or "no-tty" depending on what you want the
> > > default to be.
> >
> > If it would be OK, I'd prefer to just have the TTY work with all MI
> > tests, not making it optional. I'd like to repost the patch with all of
> > the problems found already, and with that additional change. Is this OK?
> >
> > My theory is that no FE can/should use MI with out separating the inferior
> > output via a pty. So, it's OK to test GDB under these assumptions.
>
> Well, first, let me ask you a question. What is the intended fate of
> the old mechanism for interleaved output? The new TTY method has at
> least two limitations:
This is very interesting. This branches into 2 areas, the testsuite and
FE's). As far as the testsuite is concerned, if we add this patch
optional (currently the way it is), then everything is fine for target's
that don't support any TTY mechanism. If we add the patch unconditionally,
then I would say that the target's that don't support TTY's are
unsupported by GDB/MI.
What is GDB's stance on supporting target's via GDB/MI that can not support
creating TTY's? Off the top of my head, I don't think it makes sense to
support these targets. You can not write a reliable FE under theses
circumstances. The inferior can spew out anything it chooses, including
partial MI fragments (if inferior == GDB).
> - As far as I know, native Win32 targets can't use PTYs:
> http://world.std.com/~jmhart/critcom.htm#UNIX%20Pseudoterminal
> So, they'll probably need something different.
In this scenario, I think Cygwin is the answer. Or use GDB/MI with an
inferior program that doesn't output anything to the terminal.
> - Remote targets that provide output currently aren't redirected onto
> the PTY; instead they'll appear interleaved, just like before.
In this scenario, I'm guessing from the sound of it that GDB just hasn't
added support for this yet. So it's a GDB bug, right? I could look into
this if I had some direction.
> Also, Andrew pretty specifically asked you to leave the mi2-* tests
> alone for this change.
Well, he definatly was against it at first, and then I thought maybe he
was changing his mind,
http://sources.redhat.com/ml/gdb-patches/2005-02/msg00110.html
Thanks,
Bob Rossi
next prev parent reply other threads:[~2005-07-31 21:20 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-30 5:54 Nick Roberts
2005-07-30 17:39 ` Bob Rossi
2005-07-30 18:08 ` Daniel Jacobowitz
2005-07-30 22:47 ` Nick Roberts
2005-07-31 1:19 ` Daniel Jacobowitz
2005-07-30 22:47 ` Nick Roberts
2005-07-30 23:03 ` Bob Rossi
2005-07-31 1:21 ` Daniel Jacobowitz
2005-07-31 13:16 ` Bob Rossi
2005-07-31 15:31 ` Daniel Jacobowitz
2005-07-31 21:20 ` Bob Rossi [this message]
2005-08-01 1:53 ` Daniel Jacobowitz
2005-08-01 2:05 ` Bob Rossi
2005-08-01 2:15 ` Daniel Jacobowitz
2005-08-01 11:32 ` Bob Rossi
2005-08-01 3:56 ` Eli Zaretskii
2005-08-01 11:30 ` Bob Rossi
2005-08-01 13:00 ` Daniel Jacobowitz
2005-08-01 13:16 ` Bob Rossi
2005-08-01 13:23 ` Daniel Jacobowitz
2005-08-01 13:31 ` Bob Rossi
2005-08-01 14:00 ` Daniel Jacobowitz
2005-08-01 14:07 ` Bob Rossi
2005-08-01 18:45 ` Eli Zaretskii
2005-08-01 19:01 ` Mark Kettenis
2005-08-01 19:25 ` Daniel Jacobowitz
2005-08-01 19:34 ` Mark Kettenis
2005-08-01 19:43 ` Bob Rossi
2005-08-01 20:48 ` Eli Zaretskii
2005-08-01 20:45 ` Eli Zaretskii
2005-08-01 20:52 ` Daniel Jacobowitz
2005-08-02 3:45 ` Eli Zaretskii
2005-08-02 3:50 ` Daniel Jacobowitz
2005-08-02 20:46 ` Eli Zaretskii
2005-08-02 20:48 ` Daniel Jacobowitz
2005-08-13 17:26 ` Bob Rossi
2005-08-13 21:41 ` Daniel Jacobowitz
2005-07-31 21:35 ` Nick Roberts
2005-07-31 21:37 ` Daniel Jacobowitz
2005-07-31 23:32 ` Nick Roberts
2005-08-01 1:51 ` Daniel Jacobowitz
2005-08-03 2:07 ` Bob Rossi
2005-08-03 12:48 ` Bob Rossi
2005-08-03 13:19 ` Daniel Jacobowitz
2005-08-03 18:22 ` Bob Rossi
2005-08-03 18:23 ` Daniel Jacobowitz
2005-08-03 18:24 ` Bob Rossi
2005-08-03 18:32 ` Daniel Jacobowitz
2005-08-03 19:31 ` Bob Rossi
2005-08-04 2:23 ` Bob Rossi
2005-08-04 2:27 ` Bob Rossi
2005-08-04 4:05 ` Daniel Jacobowitz
2005-08-04 13:07 ` Bob Rossi
-- strict thread matches above, loose matches on Subject: below --
2005-07-27 3:18 Bob Rossi
2005-08-13 22:04 ` Mark Kettenis
2005-08-20 9:07 ` Bob Rossi
2005-08-30 2:55 ` Daniel Jacobowitz
2005-09-01 0:52 ` Bob Rossi
2005-09-01 22:12 ` Mark Kettenis
2005-09-01 23:52 ` Bob Rossi
2005-09-05 19:52 ` Bob Rossi
2005-09-10 4:02 ` Daniel Jacobowitz
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=20050731212021.GA24144@white \
--to=bob@brasko.net \
--cc=gdb-patches@sources.redhat.com \
--cc=nickrob@snap.net.nz \
/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