From: Bob Rossi <bob@brasko.net>
To: Nick Roberts <nickrob@snap.net.nz>
Cc: gdb-patches@sources.redhat.com
Subject: Re: MI testsuite to use PTY for inferior
Date: Sat, 30 Jul 2005 17:39:00 -0000 [thread overview]
Message-ID: <20050730173855.GA21401@white> (raw)
In-Reply-To: <17131.5769.342629.658975@farnswood.snap.net.nz>
> I've looked at your patch and have some comments. I'm not very familiar
> with expect so some of what I say might be wrong.
Nick, thanks for taking the time.
> > +# INFERIOR_PTY should be set to TRUE to have the inferior work with it's
> > +# own PTY. If set to FALSE, the inferior shares GDB's PTY.
> > #
> > # When running over NFS, particularly if running many simultaneous
> > # tests on different hosts all using the same server, things can
> > # get really slow. Give gdb at least 3 minutes to start up.
> > #
> > -proc mi_gdb_start { } {
> > +proc mi_gdb_start { args } {
> > global verbose
> > global GDB
> > global GDBFLAGS
> > @@ -99,6 +105,10 @@
> >
> > gdb_stop_suppressing_tests;
> >
> > + if { [llength $args] == 1} {
> > + set inferior_pty [lindex $args 0]
> > + }
> > +
> > # Start SID.
> > if { [info procs sid_start] != "" } {
> > verbose "Spawning SID"
> > @@ -117,6 +127,16 @@
> > exit 1
> > }
> > }
> > +
> > + # spawn off the new pty for the inferior process
>
> Open a new pty for the inferior process? (spawn means new process?)
I used the verb "spawn" because in order to get a new pty you have to
call 'spawn pty'. If it is prefered to say "Create the new pty ...", I
can change that.
> > + if { [ info exists inferior_pty ] } {
> > + spawn -pty
> > + global mi_inferior_spawn_id
> > + global mi_inferior_tty_name
> > + set mi_inferior_spawn_id $spawn_id
> > + set mi_inferior_tty_name $spawn_out(slave,name)
> > + }
> > +
>
> This seems to try to open a new pty even if inferior_pty is false. Shouldn't
> the condition, here and elsewhere, be:
>
> if { $inferior_pty } {
I think this could be a style issue, but I'm not sure. I only create the
inferior_pty variable if mi_gdb_start's INFERIOR_PTY is true. Then I
check in later calls to see if the variable inferior_pty exists via
'info exists inferior_pty'.
I'm pretty sure this is equivalent to always creating the variable
inferior_pty and always assigning it a true/false value based on
INFERIOR_PTY. Then I could do an if on it's value, instead of simply
it's existence.
Is one of these approaches prefered over the other in GDB's testsuite or
in TCL programming?
> > -# mi_gdb_test COMMAND PATTERN MESSAGE -- send a command to gdb; test the result.
> > +# mi_gdb_test COMMAND PATTERN IPATTERN MESSAGE -- send a command to gdb; test the result.
> > #
> > # COMMAND is the command to execute, send to GDB with send_gdb. If
> > # this is the null string no command is sent.
> > # PATTERN is the pattern to match for a PASS, and must NOT include
> > # the \r\n sequence immediately before the gdb prompt.
> > +# IPATTERN is the pattern to match for the inferior's output. This will not
> > +# produce a PASS if successfull, but will produce a FAIL if unsuccessful.
> > # MESSAGE is an optional message to be printed. If this is
> > # omitted, then the pass/fail messages use the command string as the
> > # message. (If this is the empty string, then sometimes we don't
> > @@ -533,14 +568,20 @@
>
> With these arguments, you can't discriminate between
>
> mi_gdb_test COMMAND PATTERN MESSAGE
>
> and
>
> mi_gdb_test COMMAND PATTERN IPATTERN
>
> (MESSAGE is optional).
Yeah, this does look like a problem. Thanks. Is there a good way to work
around this in TCL? Or should I make the IPATTERN parameter necessary?
Force the user to put "" for IPATTERN?
Or rather, should I make the MESSAGE parameter necessary? I have a feeling
that all of the MI tests use the MESSAGE parameter. If I do that, I can
make the IPATTERN parameter optional, and last.
> Re your ChangeLog entry,
> > + * gdb.mi/mi-console.exp: Ditto.
> > + (47-exec-next): Use mi_gdb_test to get GDB and Inferior output.
>
> 47-exec-next isn't a procedure. I would just do:
>
> * gdb.mi/mi-console.exp: Use mi_gdb_test to get GDB and Inferior output.
>
> I know that "Ditto." and "Likewise." are used often in GDB but I prefer:
>
> * gdb.mi/gdb669.exp, gdb.mi/gdb680.exp, gdb.mi/gdb701.exp,
> gdb.mi/gdb792.exp, gdb.mi/mi-break.exp, gdb.mi/mi-disassemble.exp,
> gdb.mi/mi-eval.exp: Tell mi_gdb_start to use a PTY for inferior.
> Update Copyright.
I will gladly change my ChangeLog sytle if either Daneil or Eli agree
with your assessment. I have currently built up my ChangeLog style as a
repetitive response from Daneil and Eli in order to comply with there
style, in order to get faster patch review time.
Thanks,
Bob Rossi
next prev parent reply other threads:[~2005-07-30 17:39 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 [this message]
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
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=20050730173855.GA21401@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