Re: lib/gdb.exp: Don't loop infinitly on download attempts

[Andrew Cagney <ac131313 at cygnus dot com>]

Stan Shebs wrote:
> 
>    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...

Yes, good point.  The test is too late.

> 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.

Unfortunatly, what I saw was the testsuite repeatedly trying ``jump
*_start'' from within that expect statement.  The expect never
terminated and gdb_run_cmd never returned.

The other options are to eliminate the exp_continue and replace the
entire thing with a loop.  Counters on each expect statement may also be
applicable - two ``jump *'' attempts are illegal while N of something
else are valid.

	Andrew