From: Fernando Nasser <fnasser@redhat.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA/testsuite] Significantly speed up commands.exp
Date: Wed, 03 Apr 2002 06:21:00 -0000 [thread overview]
Message-ID: <3CAB0F53.D96BF21B@redhat.com> (raw)
In-Reply-To: <20020403012054.A28087@nevyn.them.org>
This apparently was a problem with HP-UX. Anyway, we should not
have to hack GDB -- HP-UX folks have to get a newer Dejagnu if
they have not done so yet.
So lets go ahead and remove the hack.
Thank you very much.
Fernando
Daniel Jacobowitz wrote:
>
> There's no good reason for how long commands.exp takes on any fast machine.
> I figured something was timing out somewhere and went digging. Sure enough,
> there's a nasty hack in gdb_expect to support -notransfer as the first
> argument to gdb_expect and pass it on to remote_expect in the same way; but
> the comment alludes to a DejaGNU bug which seems to be long gone. At least,
> I couldn't find it in any version of DejaGNU I looked at. Similarly, since
> 1994 at least and probably earlier, expect has wanted -notransfer before the
> individual -re entries, not before the whole block.
>
> Killing the hack saves about a minute in timeouts; every line of a
> multi-line command was pausing for two seconds. This makes my 4-way test
> runs a little happier. I think there's another culprit somewhere, but
> before this patch:
>
> real 23m38.255s
> user 8m22.000s
> sys 1m44.880s
>
> Afterwards, it should be about 19min. Wall clock twice system time used
> isn't too shabby, since there's a lot of I/O involved.
>
> OK to commit?
>
> --
> Daniel Jacobowitz Carnegie Mellon University
> MontaVista Software Debian GNU/Linux Developer
>
> 2002-04-02 Daniel Jacobowitz <drow@mvista.com>
>
> * lib/gdb.exp (gdb_test): Move -notransfer inside of gdb_expect.
> (gdb_expect): Remove $notransfer hack.
>
> Index: gdb.exp
> ===================================================================
> RCS file: /cvs/src/src/gdb/testsuite/lib/gdb.exp,v
> retrieving revision 1.14
> diff -u -p -r1.14 gdb.exp
> --- gdb/gdb/testsuite/lib/gdb.exp 2001/10/02 19:42:10 1.14
> +++ gdb/gdb/testsuite/lib/gdb.exp 2002/04/03 06:14:12
> @@ -440,9 +440,9 @@ proc gdb_test { args } {
> # we need to set -notransfer expect option so that
> # command output is not lost for pattern matching
> # - guo
> - gdb_expect -notransfer 2 {
> - -re "\[\r\n\]" { }
> - timeout { }
> + gdb_expect 2 {
> + -notransfer -re "\[\r\n\]" { verbose "partial: match" 3 }
> + timeout { verbose "partial: timeout" 3 }
> }
> set string [string range "$string" [expr $foo + 1] end];
> } else {
> @@ -1132,20 +1132,6 @@ proc send_gdb { string } {
> #
>
> proc gdb_expect { args } {
> - # allow -notransfer expect flag specification,
> - # used by gdb_test routine for multi-line commands.
> - # packed with gtimeout when fed to remote_expect routine,
> - # which is a hack but due to what looks like a res and orig
> - # parsing problem in remote_expect routine (dejagnu/lib/remote.exp):
> - # what's fed into res is not removed from orig.
> - # - guo
> - if { [lindex $args 0] == "-notransfer" } {
> - set notransfer -notransfer;
> - set args [lrange $args 1 end];
> - } else {
> - set notransfer "";
> - }
> -
> if { [llength $args] == 2 && [lindex $args 0] != "-re" } {
> set gtimeout [lindex $args 0];
> set expcode [list [lindex $args 1]];
> @@ -1186,7 +1172,7 @@ proc gdb_expect { args } {
> }
> }
> set code [catch \
> - {uplevel remote_expect host "$gtimeout $notransfer" $expcode} string];
> + {uplevel remote_expect host $gtimeout $expcode} string];
> if [info exists old_val] {
> set remote_suppress_flag $old_val;
> } else {
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
next prev parent reply other threads:[~2002-04-03 14:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-02 22:20 Daniel Jacobowitz
2002-04-03 6:21 ` Fernando Nasser [this message]
2002-04-03 8:17 ` Daniel Jacobowitz
2002-04-03 7:19 Michael Elizabeth Chastain
2002-04-03 7:30 ` Fernando Nasser
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=3CAB0F53.D96BF21B@redhat.com \
--to=fnasser@redhat.com \
--cc=drow@mvista.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