Make sure catch-syscall.exp doesn't pick up system/installed syscalls xml.

[Pedro Alves <pedro at codesourcery dot com>]

On Tuesday 06 October 2009 09:48:04, Pedro Alves wrote:
> On Tuesday 06 October 2009 05:44:08, Sérgio Durigan Júnior wrote:
> 
> > Also, there's one more thing I'd like to point out.  The catch syscall 
> > testcase partially relies in the fact that GDB will not have the data-
> > directory automatically set on startup. 
> 
> The tests run with "gdb -nx", thus garanteed to skip any
> .gdbinit file.  (I did check that the patch had introduced no
> regressions.)
> 
> > This is because, among other things,  
> > it has to test how GDB behaves when it doesn't have access to the XML files 
> > for the architecture (or even when those files don't exist at all), and this 
> > scenario is achieved when data-directory is empty.
> 
> But, data-directory isn't empty by default.
> 
>  (gdb) show data-directory
>  GDB's data directory is "/usr/local/share/gdb".
> 
> > Anyway, if we decide to make this parameter be automatically set upon GDB's 
> > initialization in the build dir, we have to make sure that this doesn't break 
> > the testcase (I didn't test this specific case yet, but IIRC it's likely that 
> > it will break).  If it does, we may need to unset it on some situations inside 
> > the testcase in order to make it work properly.
> 
> Oh, the test is broken if the default system data-directory
> _does_ have contents in it, from a previous installation.  Easy to test.  See:
> 
> Using the default /usr/local/ prefix, no gdb installed yet:
> 
> $ make check RUNTESTFLAGS="catch-syscall.exp"
>  ...
>  # of expected passes            45
> 
> $ sudo make install
>  ... yadda, yadda ...
> 
> $ make check RUNTESTFLAGS="catch-syscall.exp"
> 
>  Running ../../../src/gdb/testsuite/gdb.base/catch-syscall.exp ...
>  FAIL: gdb.base/catch-syscall.exp: Catch syscall displays a warning when there is no XML support
>  FAIL: gdb.base/catch-syscall.exp: catch syscall with arguments (3)
>  FAIL: gdb.base/catch-syscall.exp: syscall(s) 3 appears in 'info breakpoints'
>  FAIL: gdb.base/catch-syscall.exp: program has called 3
>  FAIL: gdb.base/catch-syscall.exp: syscall 3 has returned
> 

I've applied the patch below to fix this.

-- 
Pedro Alves

2009-11-22  Pedro Alves  <pedro@codesourcery.com>

	* gdb.base/catch-syscall.exp (test_catch_syscall_fail_nodatadir)
	(do_syscall_tests_without_xml): Set data-directory to
	/the/path/to/nowhere.

---
 gdb/testsuite/gdb.base/catch-syscall.exp |   10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

Index: src/gdb/testsuite/gdb.base/catch-syscall.exp
===================================================================
--- src.orig/gdb/testsuite/gdb.base/catch-syscall.exp	2009-11-22 22:23:49.000000000 +0000
+++ src/gdb/testsuite/gdb.base/catch-syscall.exp	2009-11-22 22:54:35.000000000 +0000
@@ -258,6 +258,10 @@ proc test_catch_syscall_fail_nodatadir {
     # Sanitizing.
     delete_breakpoints
 
+    # Make sure GDB doesn't load the syscalls xml from the system data
+    # directory.
+    gdb_test "set data-directory /the/path/to/nowhere" ""
+
     # Testing to see if we receive a warning when calling "catch syscall"
     # without XML support (without datadir).
     set thistest "Catch syscall displays a warning when there is no XML support (no datadir set)"
@@ -382,9 +386,9 @@ proc test_catch_syscall_with_wrong_args_
 proc do_syscall_tests_without_xml {} {
     global gdb_prompt srcdir
 
-    # In this case, we don't need to set GDB's datadir because
-    # we want GDB to display only numbers, not names.  So, let's
-    # begin with the tests.
+    # Make sure GDB doesn't load the syscalls xml from the system data
+    # directory.
+    gdb_test "set data-directory /the/path/to/nowhere" ""
 
     # Let's test if we can catch syscalls without XML support.
     # We should succeed, but GDB is not supposed to print syscall names.