Re: Avoid timeouts in call-sc.exp

[Michael Chastain <mec dot gnu at mindspring dot com>]

Paul Gilliam <pgilliam@us.ibm.com> wrote:
> What is the purpose of 'try_finish'?  I don't see how the test 'if
> (try_finish == 0)' will ever fail to be true.  What am I missing?

The idea is to allow either this:

  backtrace 1
  #0 int main() ... blah
  (gdb) PASS: return foo; synchronize pc to main

Or this:

  backtrace 1
  #0 ... fun () ... blah
  #1 int main () ... blah
  (gdb) finish
  finishing ... blah
  (gdb) backtrace 1
  #0 int main () ... blah
  (gdb) PASS: return foo; synchronize pc to main

In the first case, the program counter is already back in main()
after the call to "return", and everything is cool.

In the second case, "return" spazzed out, and the program counter
is still left back inside fun().  That's the case that attracted
you to call-sc.exp.

What I tried to write was:

  int try_finish = 0;
  while (gdb is stuck in fun())
  {
    if (try_finish == 0)
    {
      try_finish++;
      tell gdb to "finish";
      continue;
    }
  }

But exp_continue does not quite work because it does not re-issue
the "backtrace 1" command.

The simple way out is not to use exp_continue:

  set test "return foo; synchronize pc to main"
  gdb_test_multiple "backtrace 1" $test {
    -re "#0.*main \\(\\).*$gdb_prompt $" {
      pass $test
    }
    -re "#0.*fun \\(\\).*$gdb_prompt $" {
      gdb_test "finish" ".*" ""
      gdb_test "backtrace 1" "#0.*main \\(\\)" $test
    }

Can you play with that?

Also I am still hoping to see the gdb.log file from your system
where call-sc.exp has this problem.