On Monday 23 August 2004 14:55, Michael Chastain wrote:
> 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.

I will play with this and post it back.

In the mean time, I have attached a couple of logs.  'ppc32.gdb.log' is an 
example of things working correctly. (It was generated using a 64-bit GDB and 
a 32-bit application-under-test).  'ppc64.gdb.log' is a partial log (I got 
tired of waiting for the timeouts).  In this case, gdb was again 64-bits but 
the application-under-test was also 64-bits.  This combination has a bug that 
caused the problem to show up.