This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Can we make gdbinit.in set the data-directory to @srcdir@?


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

-- 
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]