* gdb.base/scope.exp: xfail 'scope0.c'::filelocal_bss before run
authorJeff Law <law@redhat.com>
Tue, 22 Aug 1995 19:09:39 +0000 (19:09 +0000)
committerJeff Law <law@redhat.com>
Tue, 22 Aug 1995 19:09:39 +0000 (19:09 +0000)
        test for PRO targets.

gdb/testsuite/ChangeLog
gdb/testsuite/gdb.base/scope.exp

index 80209f95668a036ff5bd06f2d58e3917061e8768..e53bda0d653262577e9ce429c29eb2177e3e80b0 100644 (file)
@@ -1,5 +1,8 @@
 Tue Aug 22 00:30:37 1995  Jeff Law  (law@snake.cs.utah.edu)
 
+       * gdb.base/scope.exp: xfail 'scope0.c'::filelocal_bss before run
+       test for PRO targets.
+
        * gdb.base/funcargs.exp: Avoid ever setting more than 8
        breakpoints in the inferior at any given time by making
        two groups of breakpoints for call2*, call6* and call7*
index a0bb7db22d7dd3261b02c69a95a13fc14a099533..5d3cf8f70b24ded77fd0a988d4978ad406428082 100644 (file)
@@ -934,6 +934,12 @@ gdb_test "print 'scope0.c'::filelocal_ro" "= 201"
 
 # gdb currently cannot access bss memory on some targets if the inferior
 # is not running.
+#
+# For PA boards using monitor/remote-pa.c, the bss test is going to 
+# randomly fail.  We've already put remote-pa on the target stack,
+# so we actually read memory from the board.  Problem is crt0.o
+# is responsible for clearing bss and that hasnt' happened yet.
+setup_xfail "hppa*-*-*pro*"
 if {$gcc_compiled} then { setup_xfail "rs6000-*-*" }
 send "print 'scope0.c'::filelocal_bss\n"
 expect {