ok, here is the new patch.  The logs are attached.

diff -Naur old/call-sc.exp new/call-sc.exp
--- old/call-sc.exp     2004-08-24 01:11:59.000000000 +0000
+++ new/call-sc.exp     2004-08-25 22:27:04.089926216 +0000
@@ -281,6 +281,30 @@
        }
     }

+    # If the previous test did not work, the program counter might
+    # still be inside foo() rather than main().  Make sure the program
+    # counter is is main().
+    #
+    # This happens on ppc64 GNU/Linux with gcc 3.4.1 and a buggy GDB
+
+    set test "return foo; syncronize pc to main()"
+    for {set loop_count 0} {${loop_count} < 2} {incr loop_count} {
+      gdb_test_multiple "backtrace 1" $test {
+        -re "#0.*main \\(\\).*${gdb_prompt} $" {
+          pass ${test}
+          set loop_count 2
+        }
+        -re "#0.*fun \\(\\).*${gdb_prompt} $" {
+          if {${loop_count} < 1} {
+            gdb_test "finish" ".*" ""
+          } else {
+            fail ${test}
+            set loop_count 2
+          }
+        }
+      }
+    }
+
     # Check that the return-value is as expected.  At this stage we're
     # just checking that GDB has returned a value consistent with
     # "return_value_unknown" set above.


-=# Paul #=-


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.