This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: lib/gdb.exp: Don't loop infinitly on download attempts
- To: cagney at cygnus dot com
- Subject: Re: lib/gdb.exp: Don't loop infinitly on download attempts
- From: Stan Shebs <shebs at cygnus dot com>
- Date: Thu, 7 Oct 1999 18:37:05 -0700
- CC: gdb-patches at sourceware dot cygnus dot com
From: Andrew Cagney <ac131313@cygnus.com>
Date: Wed, 06 Oct 1999 13:00:25 +1000
Wed Oct 6 12:05:58 1999 Andrew Cagney <cagney@b1.cygnus.com>
* lib/gdb.exp (gdb_run_cmd): Give up after five download attempts.
The theory is attractive, although I would suggest three download attempts,
two seems to be giving up too quickly, five seems excessive. But I have
a question about the logic:
*************** proc gdb_run_cmd {args} {
*** 204,209 ****
--- 207,217 ----
}
-re "No symbol \"start\" in current.*$gdb_prompt $" {
send_gdb "jump *_start\n";
+ set load_attempts [expr $load_attempts - 1]
+ if [expr $load_attempts <= 0] {
+ perror "Load failed"
+ return
+ }
exp_continue;
So what's happening here is that jumping to "start" (actually should
be matching "$start", that's what was sent) has failed, so we try a
fallback of jump *_start instead. But then, instead of expecting a
reply, we immediately count down load_attempts and return if 0,
counting this as a failure. Meanwhile, the jump to _start may actually
have succeeded...
I think the right thing to do is to start the countdown in gdb_load
and then count down/fail on the error returns in gdb_run_cmd rather
than the continues.
Stan