From b9ba33e6f02811f1160a1209fadc0fd5401114da Mon Sep 17 00:00:00 2001 From: Jeff Law Date: Tue, 22 Aug 1995 19:09:39 +0000 Subject: [PATCH] * gdb.base/scope.exp: xfail 'scope0.c'::filelocal_bss before run test for PRO targets. --- gdb/testsuite/ChangeLog | 3 +++ gdb/testsuite/gdb.base/scope.exp | 6 ++++++ 2 files changed, 9 insertions(+) diff --git a/gdb/testsuite/ChangeLog b/gdb/testsuite/ChangeLog index 80209f95668..e53bda0d653 100644 --- a/gdb/testsuite/ChangeLog +++ b/gdb/testsuite/ChangeLog @@ -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* diff --git a/gdb/testsuite/gdb.base/scope.exp b/gdb/testsuite/gdb.base/scope.exp index a0bb7db22d7..5d3cf8f70b2 100644 --- a/gdb/testsuite/gdb.base/scope.exp +++ b/gdb/testsuite/gdb.base/scope.exp @@ -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 { -- 2.30.2